NAVAL  POSTGRADUATE  SCHOOL 
Monterey,  California 


THESIS 


DEVELOPMENT  OF  A  CIVIL  ENGINEER  CORPS 

COMMUNITY  PORTAL  PROTOTYPE 

by 

Neil  Christopher  Rader 

June  2002 

Thesis  Advisor: 

Dale  M.  Courtney 

Second  Reader: 

Glenn  R.  Cook 

Approved  for  public  release;  distribution  is  unlimited 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


REPORT  DOCUMENTATION  PAGE 


Form  Approved  OMB  No.  0704-0188 
Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including 
the  time  for  reviewing  instruction,  searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and 
completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any 
other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington 
headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite 
1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project 
(0704-0188)  Washington  DC  20503.  _ _ 

I.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

June  2002  Master’s  Thesis 

4.  TITLE  AND  SUBTITLE:  Development  of  a  Civil  Engineer  Corps  Community  5.  LENDING  NUMBERS 
Portal  Prototype _ 

6.  AUTHOR(S)  Neil  Christopher  Rader  _ 

7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PEREORMING 

Naval  Postgraduate  School  ORGANIZATION  REPORT 

Monterey,  CA  93943-5000  NUMBER 

9.  SPONSORING  /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES)  10.  SPONSORING/MONITORING 
N/A  AGENCY  REPORT  NUMBER 

II.  SUPPLEMENTARY  NOTES  The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official 

policy  or  position  of  the  Department  of  Defense  or  the  U.S.  Government. _ 

12a.  DISTRIBUTION  /  AVAll.ABll  JTY  STATEMENT  12b.  DISTRIBUTION  CODE 

Approved  for  public  release;  distribution  is  unlimited 

13.  ABSTRACT  (maximum  200  words) 

The  Civil  Engineer  Corps  (CEC)  is  a  relatively  small  Navy  community  consisting  of  approximately  1300  officers.  Billets  for 
the  CEC  are  located  around  the  world,  and  the  community  requires  the  ability  to  disseminate  information  as  efficiently  as 
possible  to  all  comers  of  the  world.  Currently,  information  resources  are  available  in  both  print  and  electronic  forms  in 
numerous  locations.  This  thesis  explores  the  concept  of  providing  a  single  on-line  location  where  CEC  officers  can  go  to 
access  personnel  and  professional  information,  in  addition  to  community  items  of  interest. 

This  thesis  researches  utilizes  a  form  of  rapid  application  development  to  deliver  a  proof-of-concept  prototype  portal,  which 
grants  the  community  access  to  the  vast  amounts  of  information  available.  In  addition  to  the  web  development  necessary  for 
this  prototype,  the  project  also  includes  the  development  of  the  relational  database  to  deliver  data  to  the  portal.  The  intent  of 
the  thesis  is  to  explore  the  possibilities  of  how  modern  web-based  technologies  can  be  leveraged  to  provide  a  wealth  of 
information  to  hundreds  of  officers  around  the  world. 

14.  SUBJECT  TERMS  Database,  Internet,  Web-enabled  15.  NUMBER  OE 

PAGES 

125 

16.  PRICE  CODE 

17.  SECURITY  18.  SECURITY  19.  SECURITY  20.  LIMITATION 

CLASSIEICATION  OE  CLASSIEICATION  OE  THIS  CLASSIEICATION  OE  OE  ABSTRACT 

REPORT  PAGE  ABSTRACT 

Unclassified  Unclassified  Unclassified  UL 


NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 
Prescribed  by  ANSI  Std.  239-18 


1 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


11 


Approved  for  public  release;  distribution  is  unlimited 


DEVELOPMENT  OF  A  CIVIL  ENGINEER  CORPS 
COMMUNITY  PORTAL  PROTOTYPE 

Neil  Christopher  Rader 
Lieutenant,  United  States  Navy 
B.S.,  Tennessee  Teehnologieal  University,  1997 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  INFORMATION  TECHNOLOGY  MANAGEMENT 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
June  2002 


Author:  Neil  Christopher  Rader 


Approved  by:  Dale  M.  Courtney 

Thesis  Advisor 


Glenn  R.  Cook 
Associate  Advisor 


Dan  C.  Boger 

Chairman,  Department  of  Information  Sciences 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


IV 


ABSTRACT 


The  Civil  Engineer  Corps  (CEC)  is  a  relatively  small  Navy  community  consisting 
of  approximately  1300  officers.  Billet  locations  for  the  CEC  range  from  Bahrain,  Saudi 
Arabia  to  Keflavik,  Iceland.  CEC  officers  have  a  broad  range  of  professional  skills 
including  contract  management,  public  works  management,  Seabee  operations,  and  other 
various  fields.  The  information  associated  with  these  fields  is  abundant,  and  a  common 
point  of  reference  would  be  beneficial  to  all  members.  The  community  is  wide  spread 
and  requires  the  ability  to  disseminate  information  as  efficiently  as  possible  to  all  comers 
of  the  world.  Currently,  information  resources  are  available  in  both  print  and  electronic 
forms  in  numerous  locations.  This  thesis  explores  the  concept  of  providing  a  single  on¬ 
line  location  where  CEC  officers  can  go  to  access  the  information  they  need. 

This  thesis  provides  a  summary  of  the  development  of  a  working  prototype  web 
portal,  which  grants  the  community  access  to  the  vast  amounts  of  information  available. 
The  intent  of  the  thesis  is  to  explore  the  possibilities  of  how  modem  web-based 
technologies  can  be  leveraged  to  provide  a  wealth  of  information  to  hundreds  of  officers 
around  the  world.  In  addition  to  the  web  development  necessary  for  this  prototype,  the 
project  also  includes  the  development  of  the  relational  database  to  deliver  data  to  the 
portal. 

The  research  focuses  on  the  methodology  used  to  develop  this  portal  prototype. 
The  methodology  used  for  the  development  of  the  project  is  a  form  of  Rapid  Application 
Development  (RAD)  including  the  following  phases:  definition,  requirements,  design, 
and  implementation.  Rapid  Application  Development  is  an  iterative  method  of  delivering 
an  end  product.  The  method  focuses  on  delivery  of  small  pieces  of  the  whole  and  builds 
up  to  the  final  deliverable  in  an  iterative  fashion. 

The  completion  of  this  thesis  project  demonstrates  that  a  community  portal  is 
viable  concept  for  information  delivery  to  the  entire  Civil  Engineer  Corps.  The  results  of 
this  thesis  can  be  used  to  pursue  implementation  of  a  similar  concept  for  use  by  the  entire 
community. 
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I.  INTRODUCTION  &  BACKGROUND 


A,  AREA  OF  RESEARCH 

The  Civil  Engineer  Corps  (CEC)  is  a  small  Navy  eommunity  consisting  of 
approximately  1300  officers.  CEC  duty  assignments  are  focused  in  three  main  areas: 
Seabee  Construction  Battalions,  Contract  Management,  and  Public  Works  Management. 
Members  spend  from  eighteen  months  to  three  years  on  station  at  each  duty  assignment. 
Billet  locations  range  from  Bahrain,  Saudi  Arabia,  to  Keflavik,  Iceland,  and  virtually 
every  Navy  and  Marine  Corps  base  in  between.  Moves  are  frequent,  and  job  descriptions 
vary  greatly.  The  information  available  to  support  this  community  and  its  many  job 
descriptions  is  vast  and  wide  spread.  Currently,  there  is  no  single  point  of  delivery  for  all 
of  this  information. 

Advances  in  technology  that  have  occurred  over  the  last  decade  have  made 
information  delivery  a  much  easier  task.  A  substantially  large  portion  of  the  population 
is  likely  to  go  straight  to  the  internet  when  they  want  to  find  information  on  any  subject. 
The  global  nature  of  the  internet  means  that  there  are  not  too  many  places  that  you  go 
where  you  cannot  find  a  way  to  “get  online”  to  access  this  vast  information  resource. 
The  number  of  internet  hosts  is  still  growing  at  an  amazing  rate.  (Zakon,  2002)  The 
World  Wide  Web  cannot  be  ignored  as  a  means  of  information  delivery. 

Given  this  powerful  information  delivery  tool,  the  Civil  Engineer  Corps  has  the 
opportunity  to  take  advantage  of  a  powerful  information  network  that  already  exists.  The 
community  is  in  need  of  a  central  access  point  for  all  community-related  information. 
Currently,  the  information  is  available  in  different  locations  and  in  different  forms 
including  web  pages  and  print  documents.  New  junior  officers  coming  into  the  Navy 
need  to  have  one  location  where  they  can  go  to  find  resources  to  help  them  develop  their 
careers  as  CEC  Officers.  Senior  officers,  reporting  to  a  specific  job  type  in  which  they 
have  not  worked  for  several  years,  need  a  place  to  go  to  find  the  information  necessary  to 
renew  their  education  in  the  specific  area  of  the  billet  to  which  they  are  assigned. 
Personnel  in  the  CEC  detailing  shop  need  a  point  of  communication  with  the  entire 
community.  All  community  members  need  the  ability  to  search  for  both  personnel  and 
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billets  based  on  current  information  maintained  by  the  detail  office.  The  internet 
provides  the  capability  to  consolidate  this  information.  The  creation  of  this  centralized 
resource  could  provide  timesavings  to  all  the  officers  in  the  community,  as  well  as  to 
community  managers,  who  can  go  to  a  single  location  to  deliver  news  and  information. 
The  concept  of  a  centralized  portal  for  the  community  is  a  viable  option  for 
accomplishing  this  task.  The  portal  would  initially  act  as  an  information  delivery  tool  but 
could  also  set  the  stage  for  the  future  use  of  the  portal  as  a  resource  sharing  and 
collaboration  tool. 

B,  RESEARCH  ISSUES 

The  primary  objective  of  this  research  is  to  explore  the  possibilities  that  the 
internet  provides  as  an  information  delivery  tool  and  to  develop  a  proof-of-concept 
prototype  showing  the  potential  for  a  community  portal.  The  research  will  focus  on 
developing  an  appropriate  delivery  tool  for  the  information  available.  Delivering  large 
amounts  of  information  in  a  single  location  can  often  overwhelm  a  user.  The  design  of 
the  portal  must  balance  quantity  with  quality  of  delivery.  Other  portals  will  be  evaluated 
for  effectiveness  during  the  development  process. 

Another  critical  issue  to  be  considered  is  the  design  methodology  to  be  used. 
Quick  delivery  of  this  prototype  is  essential,  and  the  method  chosen  to  develop  it  will 
affect  the  possibility  of  quick  development.  Options  considered  include  a  classic 
waterfall  approach,  a  spiral  methodology,  an  incremental  approach,  or  rapid  application 
development.  Rapid  application  development  will  be  used  as  it  incorporates  the  best 
aspects  of  the  other  methodologies  into  a  single  approach.  (Osmundson,  2002) 

A  final  issue  of  great  importance  that  must  be  studied  is  the  data  model  necessary 
to  support  the  delivery  of  this  information.  This  is  of  utmost  importance  and  will 
consume  a  large  portion  of  the  project  development.  The  information  to  be  delivered  via 
the  portal  includes  personnel  information,  information  resource  links,  billet  information, 
news,  awards,  and  other  information  as  discovered  throughout  the  development  of  the 
project.  This  information  is  highly  suited  for  database  delivery.  The  research  will 
concentrate  heavily  on  the  development  of  a  data  model  appropriate  for  the  support  of 
this  data. 
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c. 


SCOPE 


The  scope  of  this  thesis  is  two-fold.  The  end  goal  of  the  project  is  to  deliver  a 
working  prototype  of  this  portal  concept  and  evaluate  the  web  as  an  information  delivery 
tool.  In  order  to  accomplish  this  goal,  the  work  will  be  split  up  into  two  sections.  The 
first  major  area  of  focus  will  be  the  relational  data  model.  The  model  will  support  the 
development  of  the  working  Microsoft  Access  database  to  support  the  functional 
prototype  portal.  Information  contained  in  the  database  will  be  of  numerous  types 
including,  but  not  limited  to,  personnel  information,  billet  information,  news  updates, 
community  awards,  and  information  resource  links.  The  second  major  focus  area  of  the 
thesis  will  be  the  development  of  the  working  prototype  portal  and  integration  with  the 
database  mentioned  previously.  The  thesis  will  demonstrate  the  viability  of  the 
community  portal  concept  and  open  the  door  for  the  future  exploration  of  such  a  project. 
This  thesis  will  not  include  the  implementation  of  the  community  portal  for  use  by 
members  of  the  Civil  Engineer  Corps;  however,  it  will  investigate  the  issues  associated 
with  such  an  effort. 

D.  METHODOLOGY  RESEARCH 

Determining  a  development  methodology  is  critical  to  the  success  of  any 
information  systems  project.  In  order  to  determine  a  proper  development  method  for  this 
project,  a  brief  review  of  the  three  primary  development  methodologies  is  provided 
below.  A  system  development  life  cycle  (SDLC)  is  a  logical  process  by  which 
developers  build  information  systems  to  solve  business  problems  and/or  needs.  A 
methodology  is  the  physical  implementation  of  the  life  cycle,  and  a  true  methodology 
should  encompass  the  entire  SDLC.  (Whitten,  1998,  pp.  72-73)  The  three 
methodologies  to  be  considered  are  Waterfall,  Incremental,  and  Spiral.  This  is  not  an  all- 
inclusive  list.  Rather,  it  is  a  list  of  general  development  categories.  The  strengths, 
weaknesses,  and  implied  risks  of  each  will  be  considered.  An  extensive  list  of  modem 
development  methodologies  can  be  seen  at 

http://www.itmweb.com/methodologv/wmethod.htm. 
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1.  Waterfall 

a.  Strengths 

•  The  waterfall  method  is  the  quiekest  and  most  straightforward  method 
by  whieh  to  obtain  a  produet. 

•  From  a  manager’s  point  of  view,  the  waterfall  design  methodology  is 
easier  to  manage  beeause  of  its  linear  nature. 

b.  Weaknesses 

•  Beeause  of  the  simple,  straightforward  nature  of  the  waterfall  method, 
it  has  limited  flexibility  throughout  the  design  proeess.  This  ereates  a 
need  for  speeifie,  conerete  requirements  determination  at  the 
beginning  of  the  projeet. 

•  In  addition,  the  waterfall  methodology  does  not  lend  itself  to 
segmented  systems  development. 

c.  Implied  Risks 

•  If  requirements  are  not  well  defined,  the  projeet  could  fail  due  to  lack 
of  direction,  because  its  linear  nature  does  not  allow  for  course 
changes. 

•  If  a  system  is  large  and  cumbersome  with  many  parts,  this  method  is 
likely  to  fail  because  of  its  inability  to  deal  with  segmented  systems. 

2,  Incremental 

a.  Strengths 

•  Incremental  design  methods  provide  some  additional  level  of 
flexibility  during  the  design  process. 

•  This  flexibility  and  the  non-linear  nature  of  this  methodology  make  it 
better  suited  to  larger,  segmented  systems. 

b.  Weaknesses 

•  Because  of  the  iterative  and  flexible  nature  of  incremental  methods, 
development  using  this  method  tends  to  be  more  time  consuming. 

•  Requirements  need  to  be  firm  but  not  concrete  in  order  to  use  this 
design  methodology  because,  although  less  rigid,  it  has  limits  to  its 
flexibility. 

c.  Implied  Risks 

•  In  a  project  with  fixed  time  duration,  this  method  can  lead  to  failure 
due  to  its  iterative  nature,  which  is  time  consuming. 

•  Requirements  that  are  not  concrete  can  lead  to  project  failure  because 
the  method  is  not  infinitely  flexible  to  change. 
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3.  Spiral 

a.  Strengths 

•  Spiral  design  and  development  methodologies  allow  the  most  flexible 
process  for  software  creation  and  implementation. 

•  This  methodology  is  non-linear  and  iterative  in  nature,  which  makes  it 
ideally  suited  for  large  multi-part  systems  without  concrete 
requirements. 

b.  Weaknesses 

•  The  fact  that  requirements  do  not  have  to  been  well  defined  for  this 
process  tends  to  make  this  the  most  costly  method  of  software 
development  because  of  the  many  changes  in  direction  throughout  the 
project. 

•  Both  of  the  strengths  listed  for  this  methodology  also  lend  to  its 
weakness,  in  that,  they  cause  the  development  process  to  be  long  and 
drawn  out. 

c.  Implied  Risks 

•  The  flexible  nature  of  this  evolutionary  methodology  allows  for  the 
possibility  of  both  cost  and  schedule  overruns. 

•  User  interaction  in  the  iterative  development  process  is  critical  and  if 
insufficient  could  cause  project  failure.  (Sorensen,  2002) 

4,  Other  Methodologies 

The  previous  section  discussed  general  design  methodologies  available  for 
development.  In  addition  to  these,  numerous  methodologies  are  variations  of  the 
aforementioned.  A  short  sampling  of  these  other  methodologies  include  Rapid 
Application  Development,  Component  Assembly  Model,  and  Concurrent  Development 
Model.  This  is  by  no  means  a  comprehensive  list  as  the  number  of  methodologies  is  very 
long.  New  unnamed  processes  are  created  often,  because  often  no  one  methodology  suits 
the  needs  of  the  development  team.  (Osmundson,  2002) 

E.  METHODOLOGY  SELECTION 

In  any  information  technology  project,  the  method  of  development  can  be  critical 
to  the  success  of  the  project.  A  form  of  Rapid  Application  Development  (RAD)  has  been 
chosen  as  the  methodology  for  this  project  because  of  its  quick  delivery  time  and  focus 
on  iterative  development  of  small  individual  parts  of  the  whole  project.  (Creative  Data, 
2002)  Rapid  Application  Development  is  not  as  clearly  defined  as  some  other 
development  methodologies.  There  are  a  few  basic  principles:  joint  design  teams, 
integrated  computer-aided  software  engineering  tools,  and  an  iterative  process.  The 
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focus  of  RAD  is  fast,  iterative  development.  (Harris,  1997,  pg.  1-1)  Small  portions  of 
the  project  are  incrementally  developed  with  the  result  being  a  complete  and  usable 
produet.  Rapid  Application  Development  has  the  strength  of  a  classie  waterfall 
methodology  with  its  structured  development  phases,  but  it  also  has  the  advantage  of 
iterative  design  phases  similar  to  a  spiral  approach. 

The  methodology  to  be  used  is  being  called  a  form  of  RAD  because  it  does  not 
follow  the  basie  prineiples  very  closely.  Joint  development  teams  will  not  be  used 
because  a  single  person  is  doing  the  development;  and  CASE  tools  will  not  specifically 
be  used  since  the  project  is  to  be  delivered  as  a  web  product  and  is  relatively  small.  The 
tools  used  for  this  development  are  discussed  in  the  next  chapter.  As  was  mentioned 
previously,  design  methodologies  are  very  numerous  and  often  modified  to  fit  the  needs 
of  the  project.  However,  follow-on  work  to  this  project  could  utilize  the  additional 
principles  of  RAD  more  closely  as  the  magnitude  of  the  project  would  be  mueh  greater. 
This  development  will  be  broken  up  into  four  phases:  definition,  requirements,  design, 
and  implementation.  A  graphical  representation  of  the  methodology  to  be  used  ean  be 
seen  in  Figure  1. 
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Figure  1.  Development  Methodology 

The  definition  phase  is  focused  on  identifying  the  users  of  the  system, 
determining  the  need  for  the  project,  and  identifying  major  functional  areas  of  the  system. 
The  requirements  phase  will  be  used  to  determine  specific  requirements  of  the  system. 
The  entity  relationship  diagram  to  support  the  portal  will  be  developed  during  this  phase 
in  addition  to  a  general  site  plan  for  the  portal. 

The  design  phase  will  include  the  development  of  the  database  schema,  including 
all  entities  and  their  attributes.  It  will  also  include  the  detailed  site  plan  for  development 
of  the  portal.  This  phase  is  iterative  and  often  overlaps  and  interacts  with  the 
requirements  phase.  Interaction  and  repetition  between  the  requirements  and  design 
phases  is  what  separates  this  methodology  from  a  traditional  waterfall  development 
process.  During  the  multiple  requirements  and  design  phases,  the  project  will  progress 


7 


from  a  paper  concept  to  a  working  prototype  through  development  cycles  for  each  part  of 
the  system  including  the  database  and  individual  segments  of  the  portal.  Each  iteration  of 
requirements  analysis  and  design  will  focus  on  an  area  of  the  project  and  work  towards 
the  end  goal  of  a  single  integrated  system. 

Since  RAD  methodology  is  being  used,  iterative  development  is  essential.  The 
requirements  and  design  phases  will  be  repeated  as  necessary  to  accomplish  the 
development  of  each  segment  of  the  project.  An  initial  focus  will  be  placed  on  defining 
the  general  requirements,  and  they  will  be  re-evaluated  during  each  phase  of  the 
development. 

The  implementation  phase  deals  with  the  final  details  of  the  project.  It  involves 
the  actual  activation  of  the  prototype  system  and  the  issues  involved  in  making  it  a 
successful  evolution.  Final  troubleshooting  of  the  integrated  system  occurs  during  this 
phase.  This  phase  will  be  limited  in  scope  for  the  purpose  of  this  research,  as  this  is  only 
a  prototype  development. 

Overall,  this  methodology  should  provide  a  quality  product  in  the  shortest  amount 
of  time.  Rapid  application  development  is  a  quick  methodology,  but  this  does  not  mean 
taking  shortcuts.  (U.C.  Davis,  2002)  It  merely  means  efficient  use  of  time.  Planning  is 
still  critical  to  the  success  of  the  project,  and  the  following  chapters  will  focus  on  the  very 
important  task  of  requirements  determination. 

F.  ORGANIZATION 

This  thesis  will  be  organized  in  the  following  manner: 

1.  Chapter  I  -  Introduction 

This  chapter  introduces  the  goals  of  the  research  and  details  the  methodology  to 
be  used  for  the  development  of  the  project. 

2,  Chapter  II  -  Project  Definition 

This  chapter  will  deal  with  the  need  for  the  project,  identification  of  users,  and 
major  functional  area  determination. 
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3.  Chapter  III  -  Project  Requirements  &  Design 

This  chapter  is  where  the  projeet  begins  to  take  shape  and  is  the  focus  of  the 
researeh.  Specifie  requirements  will  be  identified  for  the  prototype  system.  It  deals  with 
the  actual  development  of  the  data  model  ineluding  all  entities  and  attributes  as  well  as 
the  web  interface  creation.  The  chapter  will  be  divided  into  5  development  phases,  whieh 
will  be  defined  in  more  detail  later. 

4.  Chapter  IV  -  Project  Implementation 

This  chapter  is  limited  in  scope.  Two  primary  issues  will  be  addressed:  the  final 
integration  of  the  database  and  web  portal  and  factors  to  be  considered  for 
implementation  of  a  similar  concept  for  use  by  the  entire  community. 

5.  Chapter  V  -  Conclusion 

This  chapter  summarizes  the  project  and  recaps  lessons  learned,  in  addition  to 
reeommending  areas  of  future  study. 

G.  BENEFITS 

The  Navy  as  a  whole  is  experimenting  with  the  use  of  portal  technology.  Naval 
Facilities  Engineering  Command  is  speeifically  working  on  a  portal  eoneept  to  support 
the  entire  NAVFAC  eommunity.  This  researeh  will  provide  ground  level  insight  into 
some  of  the  issues  assoeiated  with  developing  an  information  delivery  tool.  This  research 
will  be  useful  in  adding  to  the  colleetive  knowledge  of  the  eommunity  eoncerning  web 
and  portal  technology.  The  product  will  provide  the  Civil  Engineer  Corps  with  a  data 
model  from  whieh  to  work  in  order  to  move  forward  with  this  type  of  project  using  their 
choiee  of  developer.  The  prototype  will  also  provide  a  conceptual  starting  point  for  the 
development  of  a  final  produet.  The  community  will  be  able  to  build  on  the  concepts 
delivered  in  this  prototype  and  change  them  as  they  see  fit  to  meet  the  needs  at  the  time 
of  implementation. 
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II.  PROJECT  DEFINITION 


A,  GENERAL 

A  key  element  to  a  suceessful  information  teehnology  project  is  a  clear  definition 
of  the  need  for  the  project,  the  major  areas  of  functionality  for  the  project,  and  the  users 
of  the  system  to  be  delivered  by  the  project.  These  elements  become  key  in  developing 
the  requirements  for  the  project.  It  is  essential  that  any  project  meet  the  requirements  for 
which  it  was  intended.  It  is  critical  to  deliver  the  requirements,  but  scope  creep  must  be 
avoided.  Proper  definition  of  the  project  and  adequate  requirements  analysis  are  effective 
strategies  for  accomplishing  the  project  goals  without  allowing  scope  creep.  This  chapter 
deals  with  the  clear  definition  of  the  project,  while  the  next  chapter  will  elaborate  greatly 
on  project  requirements. 

B,  PROJECT  NEED 

The  Civil  Engineer  Corps  could  benefit  greatly  from  a  central  location  for 
accessing  community  specific  information.  Two  specific  points  make  this  need  ideally 
suited  to  an  online  solution: 

•  Civil  Engineer  Corps  officers  are  spread  around  the  world. 

•  The  amount  of  information  available  to  be  shared  is  tremendous. 

Given  these  points,  it  is  clear  that  a  single  web-based  resource  providing  access  to 
the  vast  amounts  of  information  would  be  an  invaluable  asset.  Additional  information  is 
needed  regarding  the  information  available  for  dissemination.  The  following  paragraphs 
detail  the  specifics  of  information  available  for  delivery  to  the  community. 

1.  Personnel  Information 

The  Civil  Engineer  Corps  detailing  shop  (Naval  Personnel  Command  Code  4413) 
manages  all  personnel  information  for  the  CEC.  This  information  includes  the 
management  of  all  personnel  in  addition  to  the  tracking  of  all  command  and  billet 
information.  This  information  is  maintained  in  a  legacy  database  system  at  Naval 
Personnel  Command  (NAVPERSCOM).  This  information  was  discovered  during  a  site 
visit  in  2001.  The  system  is  an  old  hierarchical  database  model,  which  is  accessed  by 
multiple  legacy  applications  for  managing  navy  Personnel.  This  system  is  nearly 
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impossible  to  interface  on  a  real-time  basis.  For  the  purposes  of  this  project,  the  goal  is 
to  provide  members  of  the  community  with  online  real-time  access  to  billet  and  personnel 
information.  This  will  be  accomplished  with  a  separate  system,  which  will  maintain  the 
data  necessary  to  provide  the  information  needed  by  the  community.  A  concurrent 
research  project  is  developing  a  method  for  sharing  data  between  the  legacy  system  and  a 
modern  relational  database.  For  the  purpose  of  the  portal  prototype,  the  data  model 
developed  will  be  similar  to  and  created  in  conjunction  with  the  other  research  project. 
The  NAVPERSCOM  system  does  not  maintain  any  personal  member  information  such 
as  home  address,  spouse  information,  phone  numbers,  and  other  information,  which  is  not 
directly  related  to  the  member’s  command.  This  additional  functionality  will  be  added  to 
the  capabilities  of  this  system. 

2,  Professional  Resources 

Professional  resources  are  another  critical  area  of  need  for  online  information 
delivery.  The  community  is  diversified  in  background,  qualifications,  and  job 
descriptions.  There  are  three  major  areas  of  focus  for  professional  development  as  a 
Civil  Engineer  Corps  officer:  Contract  Management,  Public  Works  Management,  and 
Seabee  Combat  Warfare.  Contract  Management  positions  focus  on  the  management  and 
oversight  of  facilities  construction  and  repair  projects.  Within  this  career  field,  there  is  a 
specific  training  path  towards  becoming  an  acquisition  professional.  The  information 
associated  with  this  training  path  is  available  in  various  locations.  Public  Works 
Management  billets  exist  in  order  to  maintain  existing  shore  facilities.  Standard  training 
and  manuals  are  available  in  order  to  assist  members  in  becoming  proficient  in  this  field. 
The  final  area  of  focus  for  CEC  officers  is  Seabee  Combat  Warfare.  These  billets  are  the 
only  operational  units  to  which  members  of  the  Corps  are  typically  assigned.  Warfare 
Qualification  is  a  critical  milestone  during  tours  in  Seabee  battalions.  Manuals  and  other 
general  information  are  available  in  order  to  prepare  members  for  their  service  in  a 
Seabee  battalion. 

In  addition  to  these  specific  areas  of  professional  development,  there  are  also  the 
areas  of  Naval  Officer  Development  and  general  Career  Development.  Resources  are 
available  to  assist  young  officers  in  the  planning  and  directing  of  their  careers  both  as 

Naval  Officers  and  as  members  of  the  Civil  Engineer  Corps. 
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3.  Community  Items  of  Interest 

In  addition  to  the  previously  mentioned  personnel  and  billet  information,  the  Civil 
Engineer  Corps  regularly  disseminates  items  of  interest  to  all  members  of  the  eommunity. 
These  items  are  delivered  in  biweekly  updates,  whieh  inelude  news  updates,  awards  to 
members,  and  orders  releases.  This  information  is  eurrently  distributed  using  e-mail  with 
a  link  to  a  web  doeument. 

C.  GENERAL  FUCNTIONALITY 

Given  the  general  deseription  of  information  resourees  available,  basie  areas  of 
system  functionality  can  be  outlined.  The  development  of  this  portal  prototype  will  focus 
on  providing  functionality  in  the  following  areas: 

•  Personnel  information  delivery  and  update  capability. 

•  Professional  information  resources  delivery. 

•  Community  items  of  interest  submission  and  delivery. 

1.  Personnel  Information 

Personnel  information  is  currently  maintained  by  NAVPERSCOM  code  4413. 
Billet  and  personnel  information  has  traditionally  been  delivered  in  a  print  media  once  a 
year.  This  information  was  limited  to  specific  information  related  to  members  of  the 
Civil  Engineers  Corps  and  their  current  billet  information.  As  this  was  an  annually 
printed  document,  it  was  out  of  date  soon  after  its  printing  and  release  to  the  community. 
Recently,  this  information  has  become  available  online  in  a  searchable  format;  however, 
the  search  capabilities  are  limited,  and  update  capability  is  not  available.  This  web  portal 
will  give  access  to  personnel  and  billet  information  as  well  as  personal  contact 
information  at  the  discretion  of  the  member.  The  portal  will  also  give  users  access  to  the 
system  in  order  to  allow  them  to  update  their  personal  information.  The  goal  will  be  to 
provide  extensive  search  capabilities,  including  various  types  of  personnel  and  billet 
searches. 

2,  Professional  Information 

The  purpose  of  this  portal  is  not  to  duplicate  existing  information.  Rather,  the 
goal  is  making  existing  information  readily  available.  Professional  information  is  the 
most  important  area  where  this  goal  must  be  kept  in  mind.  There  are  vast  resources 
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available  to  deliver  the  professional  development  information  needed  by  members  of  the 
Civil  Engineer  Corps.  In  order  to  make  use  of  these  extensive  resources,  members  must 
be  able  to  locate  the  information  that  they  need.  This  portal  will  provide  a  jumping  point 
to  information  resources  available  in  other  locations  on  the  World  Wide  Web  or  intranets 
of  various  commands.  Information  will  only  be  made  accessible  directly  from  this  portal 
when  no  information  is  currently  available  in  an  online  format  for  members  of  the 
community. 

3,  Community  Items  of  Interest 

Community  interest  items  are  currently  delivered  via  e-mail  to  members  of  the 
CEC.  This  method  of  delivery  was  recently  switched  from  a  print- and-mail  method, 
which  had  been  used  for  several  years,  to  an  e-mail  providing  a  link  to  a  web  document 
(http://www.navfac.navv.mil/pao-graphics/CECBiweeklvQ2Q6Q7.htm).  Typical  items  of  interest 
delivered  to  the  community  include  news  updates,  award  presentations,  and  orders 
releases.  Other  information  is  periodically  delivered  including  promotion  selections  and 
other  general  community  information  as  it  arises.  This  project  will  make  this  information 
available  on  a  continuing  basis.  Information  will  be  delivered  based  on  the  current  date 
and  the  date  of  the  item  of  interest.  Users  will  have  access  to  the  system  in  order  to 
submit  new  items  for  delivery  to  the  community  via  the  portal. 

4,  Database  Capability 

The  database  to  support  this  web  portal  concept  is  an  essential  part  of  the 
development.  MS  Access  will  be  used  to  develop  a  relational  database  that  will  be  easily 
accessible  from  the  web  development  environment  using  an  ODBC  connection.  The 
database  development  will  include  the  creation  of  all  tables  and  their  relationships.  In 
addition.  Access  will  be  used  for  the  Database  Management  System  (DBMS).  This 
functionality  will  provide  quick,  easy  access  to  the  information  and  will  not  be  dependent 
on  a  connection  to  the  web.  This  capability  will  be  useful  in  the  early  stages  of 
development  when  populating  the  database  with  data  in  order  to  test  web  developments. 
The  Access  DBMS  will  also  be  usable  for  users  of  the  system  after  development,  and  that 
fact  will  be  kept  in  mind  during  the  creation  of  the  data  access  forms. 
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D,  USER  IDENTIFICATION 


This  project  is  limited  in  scope,  as  it  is  meant  to  be  a  proof-of-concept  prototype 
demonstrating  the  viability  of  such  a  concept  for  the  entire  community.  Because  of  this 
fact,  the  variety  of  users  having  access  to  the  system  will  be  limited.  All  users  will  be 
treated  the  same  for  access  to  the  portal.  The  user  experience  will  not  be  customized 
based  on  who  the  user  is;  rather,  the  users  will  be  defined  for  the  purpose  of  this  project 
as  a  Civil  Engineer  Corps  officer  needing  access  to  all  of  the  above  described  information 
and  capabilities.  An  advanced  section  will  be  available  for  the  administration  of  some 
portions  of  the  database.  This  will  be  the  only  distinction  in  users.  The  administration 
section  will  require  different  credentials  in  order  to  gain  access.  Figure  2  shows  an 
interaction  diagram  between  users  and  the  elements  of  the  system. 


Figure  2.  System  Interaction  Diagram 

E.  FEASABILITY 

Based  on  the  need  and  general  functionality  defined  above,  this  project  is  viable 
for  completion.  The  limited  functionality  of  the  prototype  keeps  the  project  simple 
enough  to  be  completed  in  a  reasonable  time  but  capable  enough  to  demonstrate  the 
applicability  of  such  a  concept  for  use  by  the  community. 

There  will  be  no  additional  cost  associated  with  the  development  of  this 
prototype.  Hardware,  including  a  workstation  and  a  server,  has  been  provided  by  the 
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Naval  Postgraduate  School  for  use  during  the  thesis  development.  All  software  needed 
for  development  has  been  provided  by  the  school,  and  there  will  be  no  labor  cost 
associated  with  development  because  the  manpower  will  be  provided  by  student  research 
time. 

As  mentioned  in  Chapter  1,  this  project  is  beneficial  to  both  the  Navy  and  the 
Civil  Engineer  Corps.  The  knowledge  gained  through  the  completion  of  this  project  will 
add  to  the  collective  capabilities  of  the  Civil  Engineer  Corps.  This  will  be  beneficial 
during  the  upcoming  development  of  an  enterprise-level  portal  for  use  by  all  members  of 
Naval  Eacilities  Engineering  Command  including  military,  civilian,  and  contractor 
personnel. 
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III.  PROJECT  REQUIREMENTS  &  DEFINITION 


A,  DEVELOPMENT  PLAN 

Rapid  Application  Development  is  used  in  this  projeet  for  providing  a  phased 
development  proeess  for  the  Civil  Engineer  Corps  eommunity  portal.  In  order  to 
properly  take  advantage  of  this  methodology,  the  projeet  must  be  broken  down  into 
segments.  The  segments  ean  be  developed  independently.  The  breakdown  of  this 
development  will  partially  refleet  the  eore  funetional  areas  of  the  project  but  will  not 
follow  them  exactly.  There  are  three  main  areas  of  information  delivery  required  for  the 
portal:  personnel  information,  professional  information,  and  eommunity  items  of  interest. 
The  projeet  will  be  broken  into  five  main  modules  for  development  purposes.  The  three 
main  areas  of  information  delivery  will  all  represent  a  development  phase.  Two 
additional  phases  will  be  added  to  the  list.  The  first  phase  is  the  development  of  the 
supporting  database  for  the  portal.  The  seeond  phase  is  the  ereation  of  the  portal  home 
page,  whieh  is  a  eulmination  of  information  from  eaeh  of  the  funetional  areas.  Eaeh 
phase  will  consist  of  requirements  analysis  and  design.  The  development  will  progress  in 
the  following  order  with  a  majority  of  the  requirements  analysis  being  done  in  the  first 
two  phases. 

•  Phase  1  -  Relational  database  development 

•  Phase  2  -  Home  page  and  interfaee  development 

•  Phase  3  -  Personnel  information  delivery 

•  Phase  4  -  Professional  information  delivery 

•  Phase  5  -  Community  items  of  interest  delivery 

Two  design  approaehes  are  available  for  the  design  of  this  project  A  top-down 
approach  involves  starting  with  high-level  strategie  goals  and  working  with  these  goals  to 
develop  a  framework  for  the  end  product.  A  bottom-up  approach  is  used  in  situation 
where  a  concept  already  exists  for  the  end  user  system.  This  portal  will  be  developed 
using  a  bottom-up  approaeh.  A  general  idea  of  what  is  to  be  provided  to  users  of  the 
portal  already  exists.  This  approaeh  will  allow  for  the  derivation  of  design  speeifies  from 
end  level  user  requirements.  (Kroenke,  2000,  pp.  41-42) 
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B. 


GENERAL  SITE  PLAN 


In  order  to  grasp  an  overall  view  of  the  projeet  seope,  a  general  site  plan  is 
provided  to  establish  a  guide  for  development.  This  general  site  plan  ean  be  seen  in 
Figure  3  and  is  representative  of  the  layout  of  the  web  portal  to  be  developed. 


Figure  3.  General  Site  Plan 
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This  plan  is  derived  from  the  general  requirements  set  forth  in  the  definition 
portion  of  this  report.  The  plan  does  not  inelude  details  of  the  speeifie  number  of  pages 
on  the  site  or  any  detail  related  to  how  those  pages  will  interaet.  During  Phases  two 
through  five,  a  detailed  site  plan  will  be  developed  based  on  the  progression  of  the  portal 
development.  The  general  site  plan  details  the  eore  areas  of  funetionality,  a  general  plan 
for  interaetion  between  modules,  and  a  representation  of  the  projeet  development  phases. 
C.  DEVELOPMENT  TOOLS 

Web  development  tools  have  expanded  greatly  in  their  eapabilities  in  reeent  years. 
Web  pages,  whieh  eould  only  be  produeed  by  an  expert  eode  writer  just  a  few  years  ago, 
ean  now  be  ereated  with  simple  point-and-eliek  tools.  Major  offerings  in  the  web 
development  software  arena  inelude  Maeromedia  Dreamweaver,  Maeromedia  Ultradev, 
Mierosoft  .Net,  Mierosoft  FrontPage,  Adobe  GoLive,  Hotdog,  and  other  lesser-known 
development  tools.  These  same  eompanies  also  offer  other  software  in  the  arena  of 
desktop  publishing  and  photo  editing,  whieh  ean  aid  in  the  development  of  web  graphies 
and  other  eontent.  Some  of  these  newer  paekages  even  provide  the  eapability  to  write 
HTML  eode  for  graphies  and  aetions  ereated  within  the  software. 

In  addition  to  the  extensive  list  of  web  development  and  graphies  editing 
software,  there  are  also  numerous  portal  development  paekages  available  for  the 
integrated  design  and  deployment  of  large  enterprise-level  portals.  This  list  of  tools 
ineludes  BEA  WebLogie,  Mierosoft  SharePoint,  IBM  WebSphere,  Oraele  9iAS,  and 
Sybase  Enterprise  Portal.  These  tools  are  foeused  on  enterprise-level  applieation 
delivery.  The  definition  of  a  portal  in  the  business  arena  is  migrating  towards 
eollaborative  interaetive  sites  with  a  foeus  on  aeeessing  enterprise  applieations.  This 
projeet  is  foeused  on  a  more  traditional  information  delivery  model  of  a  portal.  The 
development  is  small  in  seale;  therefore,  portal  development  produets  will  not  be  used  for 
the  ereation  of  this  prototype. 

Based  on  previous  experienee  Maeromedia  Dreamweaver,  Ultradev  4  has  proven 
to  be  an  invaluable  development  tool  in  the  ereation  of  web  pages  and  web-aeeessible 
database  applieations.  This  software  will  be  used  for  the  development  of  this  portal.  In 
addition,  other  software  will  be  used  for  ereation  of  the  web  eontent.  Adobe  Photoshop  6 
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and  Macromedia  Fireworks  4  are  exeellent  resourees  for  web  graphie  eontent 
development.  Microsoft  Visio  2002  will  be  used  for  the  development  of  the  entity 
relationship  diagram  and  the  site  plan  diagrams.  Visio  provides  industry  standard 
charting  capabilities  and  interaetion  with  web  pages  and  databases.  Visio  was  primarily 
ehosen  for  this  research  work  because  of  its  high-level  of  eompatibility  with  other 
produets  in  the  Mierosoft  suite.  Its  modeling  eapabilities  are  suffieient  for  this  small 
projeet.  There  is  only  one  additional  eapability  that  would  be  utilized  on  a  projeet  of  this 
size  -  the  ability  to  ereate  a  database  direetly  from  the  model.  Mierosoft  Aecess  2002 
will  be  used  for  the  development  of  the  relational  database  that  will  be  used  to  support  the 
portal.  Mierosoft  Aeeess  provides  robust  database  eapability  for  small  applieations. 

D,  GENERAL  REQUIREMENTS 

The  final  desired  deliverables  beeome  a  starting  point  for  the  identifieation  of 
requirements,  when  using  a  bottom-up  approach.  Using  the  neeessary  deliverables  as  a 
point  of  reference  for  the  derivation  of  requirements  ensures  that  the  system  will  be  built 
from  the  bottom  up  with  the  end  user  requirements  at  the  eore.  Initial  requirements 
analysis  will  be  focused  on  identifying  all  the  functional  requirements  of  the  portal 
identified  by  development  phase.  Table  1  identifies  these  requirements.  Eaeh 
requirement  will  be  diseussed  in  detail  in  the  appropriate  development  phase,  and 
additional  requirements  will  be  identified  in  later  phases  of  the  projeet  as  neeessary. 


20 


Phase  1  -  Relational  database  development 

Store  data  in  an  easy-to-manage  relational  database 

Provide  a  normalized  data  model  based  on  the  informtion  needs  of  the  portal 
Provide  database  management  capabilities 
Phase  2  -  Web  portal  home  page  and  interface  development 
Allow  quick  member  search  by  last  name 
Display  missing  e-mail  address  count 
Allow  quick  submission  of  missing  e-mails 
Allow  quick  access  to  personal  information  updates 
Provide  user  friendly  main  interface 
Provide  a  common  access  menu  structure 
Display  recent  community  news 
Display  recent  community  orders  releases 
Display  recent  community  award  presentations 
Allow  user  login  and  session  tracking 
Phase  3  -  Personnel  information  delivery  tools  development 
Allow  activity  searches 
Provide  detailed  activity  search  results 
Allow  member  searches 
Provide  detailed  member  profile  search  results 
Allow  billet  searches 

Phase  4  -  Professional  information  delivery  tools  development 

Provide  links  to  acquisition  professional  information 
Provide  links  to  public  works  management  information 
Provide  links  to  Seabee  combat  warfare  information 
Provide  links  to  general  CEC  career  development  information 

Phase  5  -  Community  items  of  interest  information  delivery  tools 
development 

Deliver  news 

Deliver  award  presentations 
Deliver  orders  releases 


Table  1.  Project  Requirements 
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E,  PHASE  1  -  RELATIONAL  DATABASE  DEVELOPMENT 

This  phase,  although  not  the  primary  focus  of  this  project,  is  critical  to  the  success 
of  the  prototype.  The  supporting  database  for  any  system  can  make  information  delivery 
easy  or  impossible  depending  on  the  design  of  the  database. 

1.  Existing  Data 

The  focus  of  this  project  is  not  to  create  a  fully  populated  database.  The  goal  is  to 
create  an  ideal  relational  model  for  the  support  of  the  portal.  Much  of  the  data  needed  to 
support  this  information  delivery  tool  is  not  available  in  a  database  format.  Specifically, 
professional  information  and  community  items  of  interest  are  not  maintained  in  a 
database.  In  fact,  the  list  of  professional  information  is  not  even  compiled.  The  links  are 
scattered  over  numerous  sites  across  the  World  Wide  Web.  The  final  category  of 
information  to  be  stored  is  personnel  information.  This  data  is  maintained  by  Naval 
Personnel  Command  Code  4413.  As  mentioned  previously,  this  information  is 
maintained  in  a  legacy  database  system.  The  data  is  not  stored  in  a  relational  model  and 
is  unavailable  for  any  type  of  link  to  the  system.  That  being  said,  the  data  can  be 
extracted  in  a  comma  separated  value  text  file,  but  again,  the  data  is  not  relational  and  is 
difficult  to  manipulate. 

Another  thesis  research  project  is  underway  currently  to  study  the  method  by 
which  the  data  can  be  linked  or  imported  to  a  stand-alone  system  for  use  by  the  staff  at 
NAVPERSCOM.  Some  data  will  be  migrated  from  this  system  for  functionality  testing 
of  the  community  portal,  but  a  complete  and  accurate  migration  is  beyond  the  scope  of 
this  thesis.  This  effort  will  be  discussed  in  more  detail  in  the  implementation  chapter. 
The  database  portion  of  this  project  will  focus  on  the  development  of  an  efficient  data 
model  that  meets  the  data  requirements  of  the  web  portal  not  an  existing  database.  This 
eliminates  many  of  the  many  difficulties  associated  with  database  migration  and/or 
population. 

2,  Data  Model  Selection 

A  data  model  type  must  be  selected  in  order  to  meet  the  requirements  of  the 
project.  Data  models  most  commonly  used  in  modern  systems  include  hierarchical, 
object-oriented,  and  relational.  Hierarchical  is  an  older  form  of  database  used  in  many 
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older  mainframe-terminal  eonfigurations.  Objeet-oriented  is  the  newest  of  these  three 
options,  but  is  eomplicated  and  often  difficult  to  work  with  in  creating  a  simple  user- 
maintained  database.  (Date,  1990)  Relational  data  models  are  commonly  used  in 
database  implementations  today.  Relational  models  provide  efficient  storage  of  data  in 
an  easy  to  understand  format.  In  a  relational  model,  information  is  stored  in  entities, 
which  are  tables  of  “related”  data.  Information  in  different  entities  is  related  according  to 
proper  relationships.  This  method  of  data  storage  follows  a  logical  pattern  of 
organization,  minimizes  duplicated  data,  and  eliminates  certain  processing  errors 
generated  by  data  stored  in  other  ways.  (Kroenke,  2000,  pp.  17-18)  The  relational 
concept  will  be  used  for  the  development  of  this  project. 

3.  Requirements  Analysis 

The  requirements  specifically  related  to  the  database  development  portion  of  this 
project  are  limited  in  quantity;  however,  the  development  of  an  efficient,  easy-to-manage 
database  is  critical  to  the  success  of  the  portal  concept.  The  requirements  for  this  phase 
are  simply  stated  as  store  data  in  an  easy-to-manage  database,  provide  a  data  model  based 
on  the  information  needs  of  the  portal  and  provide  database  management  capabilities. 

The  information  identified  as  data  requirements  is  derived  from  two  primary 
sources.  The  first  is  the  print  version  of  the  PI  Civil  Engineer  Corps  directory.  This 
document  is  a  guide  for  identifying  the  information  required  for  proper  tracking  of 
community  personnel  information.  Two  sample  pages  from  this  document  are  included 
in  Appendix  A.  The  second  source  for  identifying  possible  data  to  be  stored  is  the  Civil 
Engineer  Corps  Bi-weekly  newsletter.  A  copy  of  the  June  7th  issue  is  included  in 
Appendix  B.  Other  information  identified  as  data  requirements  comes  from  the 
developer’s  knowledge  of  the  community  and  the  requirements  for  the  web  portal. 

In  addition  to  the  development  of  the  data  model  and  the  Access  database, 
database  management  must  be  included.  Eor  this  project,  the  form  creation  capability  of 
MS  Access  will  be  utilized.  A  Database  Management  system  is  necessary  in  order  to 
provide  access  to  and  maintain  the  data.  Additional  database  management  will  be 
provided  to  the  end  user  through  the  web  interface,  and  this  will  be  discussed  later  in  this 
chapter. 
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4. 


Database  Schema 


The  exact  details  of  a  database  are  explained  in  detail  using  the  schema.  The 
schema  includes  the  entities,  attributes,  domains,  and  the  business  rules  for  the  database. 
The  schema  is  a  design  for  the  database.  (Kroenke,  2000,  pg.  30)  Based  on  the  specific 
database  requirements  and  the  overall  core  functionality  of  the  system,  a  database  schema 
model  can  be  developed.  In  order  to  begin  development  of  the  data  model,  a 
brainstorming  session  is  necessary  to  identify  entities  to  store  in  the  database.  Figure  4 
shows  the  results  of  this  session. 


Figure  4.  Brainstorming  Session  Results 

The  goal  of  the  brainstorming  session  is  to  develop  a  list  that  will  be  refined  and 
become  the  list  of  entities  for  the  data  model.  The  Entity  Relationship  Diagram  can  be 
developed  based  on  a  refined  list.  Based  on  the  results  of  the  brainstorming  session  and 
further  consideration  of  data  to  be  stored.  Table  2  provides  a  list  of  entities  that  have  been 
identified  as  primary  for  the  data  model.  This  list  does  not  include  intersection  tables  or 
lookup  tables.  These  will  be  discussed  in  detail  in  the  E-R  Diagram  section. 
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MEMBER  PHONE 

BILEET  ADDRESS 

ACTIVITY  EMAIE 

ACTIVITYPHONE  AWARDS 

QUAEIEICATION  NEWS 

PCODE  EINKS 


Table  2.  Primary  Entity  Eist 
a.  E-R  Diagram  Creation 

The  primary  information  to  be  stored  in  the  database  is  personnel 
information.  This  ineludes  information  related  to  members,  aetivities,  and  billets. 
Additional  information  ineluded  in  the  model  is  related  to  the  submission  of  news 
updates,  awards,  and  links  to  items  of  interest  for  the  eommunity. 

The  simplified  Entity  Relationship  Diagram  is  shown  in  Eigure  5.  It 
shows  the  relationship  between  all  of  the  primary  entities  for  this  model.  The  detailed  E- 
R  Diagram  with  all  attributes  defined  will  follow.  The  logie  for  the  Simple  E-R  Diagram 
is  as  follows. 
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The  MEMBER  entity  represents  a  member  of  the  Civil  Engineer  Corps. 
Members  have  addresses,  phone  numbers,  and  email  address.  Eaeh  member  ean  have 
from  zero  to  many  of  eaeh.  ADDRESS,  PHONE,  and  EMAIE  are  the  entities  that 
represent  this  data.  All  addresses,  phone  numbers,  and  email  addresses  must  be 
associated  with  a  member,  but  a  member  does  not  have  to  have  any  of  the  above.  Each 
member  can  have  many  Pcodes  and  qualifications  represented  by  the  PCODE  and 
QUAEIEICATION  entities.  There  are  many  qualifications  and  pcodes.  Each  member 
can  have  from  zero  to  many  of  each.  Pcodes  and  qualifications  need  not  have  a  member. 

Members  are  assigned  to  billets  represented  by  the  BILEET  entity.  Each 
member  must  be  assigned  to  a  billet,  but  a  billet  does  not  have  to  have  a  member.  A 
member  can  be  assigned  to  many  billets  during  his  or  her  career.  Billets  are  associated 
with  an  activity  represented  by  the  ACTIVITY  entity.  An  activity  can  have  many  billets, 
but  a  billet  can  only  be  associated  with  one  activity.  An  activity  is  not  required  to  have  a 
billet,  but  a  billet  must  be  associated  with  an  activity.  Each  activity  can  have  from  zero 
to  many  phone  numbers  stored  in  ACTIVITY  PHONE.  A  billet  can  have  one  pcode  as 
represented  by  the  PCODE  entity,  but  this  is  not  required.  A  pcode  does  not  have  to  be 
associated  with  a  billet.  Each  billet  can  have  a  primary  and  a  secondary  qualification 
requirement.  This  information  is  stored  in  the  QUAEIEICATION  entity.  A  billet  is  not 
required  to  have  any  qualifications,  and  qualification  does  not  have  to  be  associated  with 
a  billet. 

Members  can  submit  community  news  updates,  which  are  stored  in  the 
NEWS  entity.  A  news  update  must  be  associated  with  the  member  who  submitted  it,  but 
a  member  does  not  have  to  have  submitted  any  news  updates.  Award  announcements  can 
be  submitted  for  members  of  the  community  and  are  stored  in  the  AWARDS  entity. 
Members  can  receive  from  zero  to  many  awards,  and  an  award  has  to  be  associated  with 
a  member.  Einks  to  professional  items  of  interest  are  to  be  stored  in  the  EINKS  entity, 
but  this  information  is  not  associated  directly  with  any  other  entity. 

Appendix  C  provides  the  detailed  database  schema  in  tabular  format.  The 
tables  include  all  of  the  entities  with  their  attributes  and  allowable  values  (domains).  The 
tables  indicate  PK  and  EK  relationships,  which  have  been  identified  as  unique,  non-data 
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carrying  integers  in  each  entity.  The  information  provided  in  the  appendix  is  very 
comprehensive;  however,  the  information  is  best  presented  in  a  graphieal  format.  Figure 
6  is  the  detailed  entity-relationship  diagram.  It  displays  all  of  the  information  from  the 
simple  E-R  Diagram,  but  also  includes  the  attributes  for  eaeh  entity,  the  intersection 
tables  necessary  for  many-to-many  relationships,  and  the  lookup  tables. 
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b.  Business  Rules 

The  final  element  of  the  database  sehema  is  the  business  rules  for  the 
database.  In  this  model,  most  of  the  data  is  constrained  by  the  model  itself  therefore 
limiting  the  number  of  business  rules  necessary.  Uniformity  of  data  input  is  the  primary 
requirement  that  is  to  be  controlled  by  a  business  rule.  In  order  to  accomplish  this  in 
certain  data  fields,  lookup  tables  are  to  be  created.  Entities  will  be  created  for  the 
following  information:  designator,  rank,  type  of  address,  type  of  phone  number,  type  of 
e-mail  address,  category  of  web  link,  category  of  billet,  state,  sex,  suffix,  and  race.  These 
entities  will  be  used  as  lookup  tables  (shown  in  Figure  7)  in  order  to  control  values 
entered  for  specific  values  in  other  entities. 


Figure  7.  Fookup  Tables 

Each  of  the  entities  will  be  prefaced  with  “lookup”  for  ease  of 
identification.  Usernames  will  be  controlled  by  a  business  rule  for  this  portal.  All 
usernames  will  be  constrained  to  first  initial,  middle  initial,  and  last  name.  As  an 
example,  Neil  Christopher  Rader  would  have  “ncrader”  as  a  username.  This  business 
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rule  will  not  be  enforeed  by  the  system.  The  input  of  usernames  will  be  eontrolled  by  the 
database  manager  when  inputting  new  users  into  the  system.  Duplieate  values  must  be 
avoided  in  order  to  suecessfully  management  portal  login  aecounts,  which  will  be 
discussed  in  detail  later. 

c.  Normalization 

The  goal  in  creating  this  relational  model  was  to  create  an  efficient 
database  that  eliminated  data  duplication  wherever  possible.  In  order  to  do  this  the 
database  needs  to  be  normalized  to  the  maximum  extent  possible.  Normalization  is  the 
process  by  which  modification  anomalies  are  eliminated  from  the  database.  The  goal  is 
to  obtain  Domain  Key/Normal  Form  (DK/NF  for  the  entire  database.  This  is  the  highest 
level  of  normalization  and  will  prevent  all  modification  anomalies.  “A  relation  is  in 
DK/NF  if  every  constraint  on  the  relation  is  a  logical  consequence  of  the  definition  of 
keys  and  domains.”  In  order  to  make  this  definition  more  clear  a  breakdown  of  the  three 
primary  definitions  in  this  statement  are  provided  below. 

A  constraint  is  defined  as  any  rule  governing  the  static  values  of  an 
attribute.  A  key  is  a  unique  identifier  for  record  in  a  table.  The  domain  for  an  attribute  is 
defined  as  the  meaning  of  the  attribute  and  the  physical  list  of  values  it  can  have.  In 
simpler  terms  “...a  relation  is  in  DK/NF  if  enforcing  key  and  domain  restrictions  causes 
all  of  the  constraints  to  be  met.”  (Kroenke,  2000,  pg.  126)  This  model  was  successfully 
normalized  to  a  high  degree;  however,  two  specific  issues  were  not  dealt  with. 

The  first  and  most  important  of  these  is  the  relationship  between  billets 
and  activities.  In  reality  this  relationship  should  be  able  to  be  represented  using  a  many- 
to-many  relationship.  A  set  of  data  could  be  defined  such  that  a  finite  list  of  billets  could 
occur  at  numerous  activities.  Instead,  the  relationship  is  represented  as  a  one-to-many 
relationship  with  one  activity  having  many  billets.  The  reason  for  this  denormalized  state 
is  the  data  available  for  the  population  of  the  database.  A  single  job  description  might 
occur  at  two  different  locations,  but  its  description  in  the  NAVPERSCOM  system  might 
be  different  from  one  activity  to  the  next.  For  an  example,  a  public  works  officer  billet 
will  be  considered.  Each  activity  that  has  a  public  works  officer  will  have  a  separate 
billet  listed  in  the  legacy  system.  One  location  may  call  this  billet  the  public  works 
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officer,  another  may  simply  list  it  as  PWO,  and  still  another  may  simply  list  it  as  the 
faeilities  director.  This  created  a  problem  with  data  migration;  therefore,  this  relationship 
was  not  normalized. 

The  seeond  issue  is  related  to  the  use  of  the  designator  lookup  table.  The 
database  was  ereated  and  the  projeet  was  well  underway,  when  this  information  was 
identified  as  something  that  had  the  potential  to  change.  The  data  is  stored  in  the 
MEMBER  and  BIEEET  entities  and  merely  looked  up  from  the  lookupDESIGNATOR 
table.  If  the  information  for  a  designator  were  to  ehange  data  updates  would  be  required 
to  both  the  MEMBER  and  BIEEET  tables.  The  proper  implementation  for  this  data 
would  be  to  relate  members  and  billets  to  designators  using  a  foreign  key  in  these  tables. 
The  implementation  would  be  similar  to  the  relationship  between  billets  and  Peodes.  In 
fact,  the  data  in  the  peode  table  would  soon  be  required  to  go  through  this  very  update 
beeause  navy  peodes  were  ehanged  reeently. 

5,  Database  Creation 

With  the  eoneeptual  design  of  the  database  eomplete,  the  Mierosoft  Aeeess 
database  ean  be  ereated.  Mierosoft  Visio  was  used  as  the  tool  for  ereation  of  the  E-R 
diagram.  The  I-CASE  tools  mentioned  earlier  eould  have  been  benefieial  in  this  primary 
area.  More  advanee  integrated  software  tools  have  the  ability  to  take  an  entity 
relationship  diagram  and  automatieally  ereate  the  database  using  the  schema. 
Unfortunately,  Visio  does  not  have  this  eapability.  Eor  this  project,  the  Microsoft  Access 
database  was  ereated  manually  in  order  to  duplieate  the  database  schema.  Eortunately, 
Visio  does  have  the  eapability  to  refresh  a  eoneeptual  data  model  drawing  by  eonnecting 
to  the  database.  This  eapability  ean  be  used  to  refresh  the  E-R  diagram  when  any  future 
ehanges  are  made  to  the  database.  With  all  tables  and  relationships  ereated  in  MS 
Aeeess,  the  database  ean  be  populated  with  a  limited  sample  of  data  for  demonstration 
purposes. 

6.  Database  Population 

The  goal  of  this  projeet  is  not  to  populate  a  fully  aeeurate  database;  eonsequently, 
a  simple  data  set  will  be  ereated  from  existing  data  in  order  to  demonstrate  the 
eapabilities  of  the  system.  Two  fiat  files  from  the  mainframe  system  at  NAVPERSCOM 
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were  used  to  populate  approximately  1300  members,  450  activities,  1200  billets,  and 
1100  sets  of  orders.  This  data  set  is  not  complete  and  is  not  up  to  date  with  all  current 
member  assignments,  but  the  data  is  sufficient  for  prototype  testing.  The  data  chosen  for 
migration  was  selected  for  ease  of  integration.  Additional  information  was  manually 
input  into  the  system  including  addresses,  phone  numbers,  e-mail  address,  and  activity 
phone  numbers.  Member  qualifications  and  pcodes  were  also  migrated  from  the  test  files 
provided  by  NAVPERSCOM.  Finally,  a  select  group  of  awards  and  news  stories  were 
input  from  recent  CEC  bi-weekly  newsletters,  in  addition  to  links  to  several  sites  with 
professional  information  for  CEC  officers. 

7.  Database  Management 

A  database  is  useless  if  the  information  in  it  cannot  be  maintained  in  an  intuitive 
user-friendly  manner.  Microsoft  Access  was  chosen  as  the  DBMS  for  this  prototype 
project.  Given  this  fact,  the  form  creation  capability  of  Access  was  selected  as  an 
interface  for  the  database  manager.  Forms  will  be  created  to  give  the  administrator 
access  to  add,  edit,  or  delete  all  records  in  the  database  using  the  GUI  interface. 

8,  Form  Creation 

In  order  to  accomplish  the  goal  of  providing  add,  edit,  and  delete  capability  for  all 
information  in  the  database,  several  forms  will  need  to  be  created.  In  addition,  a  central 
switchboard  form  will  be  created  to  grant  access  to  each  of  the  individual  forms.  The 
following  is  a  list  of  all  forms  to  be  created,  and  Figure  8  is  a  graphical  representation  of 
how  they  interact  with  one  another. 

•  Main  Switchboard 

•  Information  Resources  Switchboard 

•  Community  Member  Management 

•  Shore  Activity  Management 

•  Shore  Billet  Management 

•  Member  Orders  Management 

•  Web  Fink  Management 

•  Award  Submission  Management 

•  News  Submission  Management 
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Figure  8.  Form  Interaction  Diagram 


These  forms  are  created  using  automated  capabilities  in  Microsoft  Access  and 
then  customized  for  more  logical  and  meaningful  arrangement  of  data.  The  main 
switchboard  is  shown  in  Figure  9,  and  the  Community  Member  Management  form  is 
shown  in  Figure  10  as  an  example  of  a  typical  management  form.  All  other  forms  are 
shown  in  Appendix  D.  The  forms  provide  access  to  all  information  in  the  database  and 
implement  the  primary  business  rule,  which  is  use  of  the  lookup  tables  mentioned  earlier. 
The  forms  limit  the  choices  in  these  fields  tr  only  those  availab’c  in  the  associated  Aokup 
table.  Figure  1 1  shows  an  example  of  this  capabdity. 
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L  Information  Delivery  Tool 


Data  Management  System 


[g1  Communitv  Member  Management 

_ I  Shore  Activity  Management 

_ I  Shore  Billet  Management 

_ I  Member  Orders  Management 

_ I  Information  Resource  Management 

_ I  Exit  Database 


Figure  9.  Main  Switchboard 


Figure  10.  Community  Member  Management 
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Figure  1 1 .  Lookup  Table  Example 

7,  Database  Testing 

The  final  step  in  the  database  phase  of  the  project  is  the  testing  phase.  Both  the 
data  model  and  the  data  management  forms  require  testing.  In  order  to  accomplish  this 
task,  several  additional  records  were  put  into  the  database  using  the  management  forms 
created  in  the  previous  section.  During  the  input  of  these  records,  various  minor  changes 
to  database  field  properties  and  form  properties  were  identified  and  corrected.  The  result 
is  a  working  system  that  allows  access  to  all  data,  maintains  rules  of  data  integrity 
required  by  the  E-R  diagram,  and  properly  implements  the  primary  business  rule  required 
for  this  development.  Several  selected  users  were  allowed  access  to  the  system  in  order 
to  confirm  its  capabilities. 

F.  PHASE  2  -  HOME  PAGE  AND  INTERFACE  DEVELOPMENT 

This  phase  is  the  development  of  the  of  the  primary  access  point  for  users  of  the 
portal.  The  development  includes  work  on  the  home  page  for  the  portal  and  the 
considerations  required  in  creating  the  entire  site.  It  is  the  hub  of  the  portal  and  is 
essential  to  success  of  the  prototype. 


36 


1. 


Server  Model  Selection 


In  order  to  begin  work  on  the  ereation  of  a  database-driven  website,  a  web  server 
model  must  be  seleeted.  Dreamweaver,  Ultradev  4  allows  for  the  ehoiee  of  three 
different  models:  Aetive  Server  Page  (ASP),  Java  Server  Page  (JSP),  and  ColdFusion 
Markup  Language  (CFML).  The  server  model  speeifies  by  what  means  the  web  pages 
will  interact  with  the  database  server.  Each  of  these  models  is  similar  in  functionality  in 
that  they  all  deliver  html  code  to  the  end  user  desktop. 

•  ColdFusion  was  created  by  Allaire  and  is  now  owned  by  Macromedia. 
ColdFusion  boasts  its  just-in-time  compiler,  which  renders  the  CFML  into 
the  pages  that  are  served.  The  CFML  code  encompasses  a  combination 
HTML  and  XML  code.  (searchDatabase.com,  2002)  ColdFusion  also 
boasts  a  very  high  level  of  interoperability  between  platforms  and 
browsers.  (Brooks-Bilson,  2001,  pp.  1-5) 

•  JSP,  as  the  name  implies,  delivers  dynamic  content  using  java  applets.  A 
Java  Server  Page  calls  a  Java  program  that  is  executed  by  the  web  server 
and  then  sent  to  the  user.  (searchSolaris.com,  2002) 

•  An  Active  Server  Page  is  a  regular  HTML  page  that  contains  one  or  more 
scripts  to  be  processed  by  the  server.  ASP  is  a  feature  of  Microsoft 
Internet  Information  Server  (IIS);  however,  since  the  scripts  are 
interpreted  on  the  server  side,  an  ASP  page  can  be  delivered  to  almost  any 
browser.  The  scripting  language  used  can  be  either  JavaScript  of 
VBScript. 

It  is  also  possible  to  run  scripts  on  the  client  side,  but  this  is  not  recommended 
because  it  can  cause  problems  with  browser  interoperability.  (searchWin2000.com, 
2002)  Each  of  these  tools  provides  access  to  essentially  any  standard  database 
connection. 

ASP  is  to  be  used  as  the  server  model  based  on  the  developer’s  knowledge  of  the 
model,  the  availability  of  a  Windows  2000  Advanced  Server  with  IIS  5.0,  and  the 
capability  to  perform  server-side  scripting  with  HTML  code  delivered  to  the  desktop. 
JavaScript  will  be  used  for  the  scripting  language.  Although  the  user  is  more  familiar 
with  VBScript,  there  are  more  resources  available  for  custom  JavaScript  expertise  on  the 
web.  The  following  section  gives  a  brief  overview  of  the  ASP  model. 
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2.  Active  Server  Page  Model 

Since  ASP  has  been  ehosen  as  the  server  model  for  this  development,  a  brief 
deseription  of  the  meehanies  behind  its  operation  is  provided  here.  Figure  12  gives  a 
graphieal  representation  of  the  elient  server  relationship  involved  in  the  model. 


Figure  12.  ASP  Server  Model 

There  are  six  Active  Server  objects.  The  Request  object  and  the  Response  are  of 
primary  eoneern.  The  request  objeet  deals  with  requests  from  the  elient  sent  to  the  site  or 
applieation  most  likely  submitted  from  an  HTML  form.  The  Response  objeet  deals  with 
the  server  response  to  the  elient  browser.  The  Applieation  and  Session  objeets  manage 
information  about  the  applieation  eurrently  running.  This  unique  instanee  of  the 
application  is  called  a  session. 

The  ObjeetContext  objeet  is  used  for  setting  timeout  properties  for  seripts  and 
eonverting  text  into  HTML  or  URLs.  The  server  objeet  is  self-explanatory,  but  the 
CreateObjeet  method  of  the  Server  objeet  is  of  great  importanee.  This  method  in 
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conjunction  with  the  ActiveX  Data  Object  (ADO)  allows  the  ability  to  create,  move, 
alter,  or  delete  records  in  the  database.  This  functionality  is  key  to  the  success  of  a  data- 
driven  web  page.  (Kauffman,  1999,  pp.  12-13) 

3.  Requirements  Analysis 

A  review  of  the  requirements  previously  identified  for  this  portion  of  the  project 
is  necessary.  They  were  defined  as: 

•  Allow  quick  member  search  by  last  name 

•  Display  missing  e-mail  address  eount 

•  Allow  quick  submission  of  missing  e-mails 

•  Allow  quick  access  to  personal  information  updates 

•  Provide  user  friendly  main  interface 

•  Provide  a  common  access  menu  strueture 

•  Display  reeent  community  news 

•  Display  recent  community  orders  releases 

•  Display  reeent  community  award  presentations 

•  Allow  user  login  and  session  tracking 

Based  on  this  list  and  the  sueeess  of  the  data  model  creation,  the  web  application 
can  be  created  to  meet  the  prescribed  requirements.  One  additional  requirement  not 
previously  identified  is  the  need  for  site  accessibility.  DoD  mandates  in  Section  508  that 
all  sponsored  sites  be  accessible  to  everyone.  (Seetion  508,  2002) 

4.  Database  Integration  and  Connection 

The  first  need  for  the  creation  of  a  data-driven  web  applieation  is  the  connection 
to  the  database.  This  proeess  has  been  streamlined  and  is  now  an  integrated  part  of 
Mierosoft  operating  systems.  Open  Database  Conneetivity  (ODBC)  is  the  method  that 
will  be  used  for  this  eonnection.  ODBC  allows  for  conneetion  to  essentially  any  standard 
database  including  SQL  Server,  Oracle,  Access,  and  others.  Dreamweaver  automatically 
recognizes  these  eonnections  and  sets  them  up  for  use  in  newly  ereated  ASP  pages. 

For  connectivity  to  the  database  for  use  on  the  web,  two  primary  methods  can  be 
used.  Both  of  these  methods  involve  the  use  of  the  Structure  Query  Language  (SQL)  for 
requesting  and  submitting  data  to  and  from  the  database.  SQL  is  the  standard  for 
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information  interchange  between  computers.  It  works  on  essentially  any  relational 
database,  and  runs  on  almost  any  computer  or  operating  system.  This  again  supports  the 
goal  of  interoperability.  SQL  is  a  data  access  language  that  uses,  SELECT,  INPUT, 
DEEETE,  and  UPDATE  commands  to  manipulate  the  database.  In  addition  other 
statements  like  WHERE  and  GROUP  BY  clauses  can  be  used  to  specify  criteria  for  the 
data  manipulations.  A  detailed  explanation  of  every  aspect  of  the  Structured  Query 
Eanguage  is  beyond  the  scope  of  this  document,  but  a  sample  SQE  statement  and  its 
explanation  are  shown  below.  In  addition.  Database  Proccessing  by  David  Kroenke  is 
recommended  as  an  excellent  introductory  text  for  the  subject. 

SEEECT  DisplayDate,  NewsID,  Title,  News 

PROM  NEWS 

WHERE  (((Month([displaydate]))=Month(Date()))) 

ORDER  BY  DisplayDate  DESC 

This  statement  requests  the  display  date,  ID,  title,  and  story  (News)  from  the  table 
NEWS  for  all  news  stories  where  the  display  month  in  the  record  is  the  same  as  the 
current  month,  and  then  sorts  the  data  from  most  recent  display  date  to  oldest  display 
date.  This  will  provide  all  news  stories  marked  for  display  in  the  current  month  and 
display  them  with  the  newest  story  on  top. 

The  first  method  by  which  dynamic  web  pages  can  gain  access  to  data  through  the 
development  environment  in  Dreamweaver  is  directly  through  recordsets.  A  recordset  is 
the  set  of  data  that  a  specific  ASP  uses.  Each  ASP  page  can  make  use  of  multiple 
recordsets  if  needed.  Using  this  method,  the  developer  directly  connects  to  the  database 
and  writes  the  SQE  statement  directly  into  the  recordset  criteria. 

The  second  method  of  data  access  using  the  combination  of  Dreamweaver  and 
MS  Access  is  to  develop  the  SQE  queries  in  the  Access  database.  The  process  is  similar 
to  the  first  method.  However,  by  creating  the  queries  in  the  database  instead  of 
Dreamweaver,  the  developer  has  direct  access  to  the  data  that  will  be  used  by  the  ASP 
page  without  the  use  of  the  web  development  environment.  This  practice  is  also 
beneficial  in  that  it  provides  easy  manipulation  and  editing  of  these  queries,  if  they 
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should  change  at  any  time.  This  method  of  database  query  will  be  used  for  this  project 
because  of  the  maintainability  that  it  provides. 

5,  Login,  Users,  and  Session  Variables 

As  was  seen  in  the  creation  of  the  database  earlier  in  this  chapter,  login 
usernames,  passwords,  and  user  levels  will  be  stored  for  all  members  of  the  community. 
Using  this  method  gives  the  website  the  capability  of  restricting  access  to  members  who 
are  listed  in  the  database  and  the  ability  to  customize  content  for  the  current  user.  The 
login  page  can  be  seen  in  Figure  13. 


Prototypa  Osvsiopment  by  LT  Chris  Rad«r  CEC,  USN 

Vim  0«v«top*d  os  Part  ol  Modor's  THaiis  l•ft•arch 


Figure  13.  Portal  Login  Page 
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The  user  level  field,  although  populated  in  the  database,  will  not  be  used  for  this 
development.  Due  to  time  eonstraints  and  the  availability  of  the  MS  Aeeess  front  end  for 
the  database,  the  administrator  portion  of  the  web  portal  will  not  be  ereated  at  this  time. 
This  variable  would  have  given  the  additional  eapability  of  granting  aeeess  to 
administration  pages  only  to  those  who  had  an  administrator  user  level. 

Session  variables  are  the  means  by  whieh  the  ASP  server  model  traeks  the  user 
while  eonneeted  to  the  site.  The  username  and  password  are  stored  in  a  session  variable 
and  earned  by  the  server  throughout  the  user’s  aetive  navigation  of  the  portal.  If  a  user 
logs  out  of  the  portal,  eloses  his  or  her  browser,  or  is  inaetive  in  the  site  for  more  than  the 
session  timeout  period,  the  session  variables  are  dropped.  The  session  variables  are 
initially  stored  after  a  suecessful  login  authentieated  to  the  approved  list  of  users  in  the 
database.  A  session  variable  ean  then  be  pulled  to  uniquely  identify  the  current  user  to  a 
database  recordset.  The  use  of  this  functionality  will  be  demonstrated  in  the  Member 
Record  Updates  section. 

6,  Web  Template  Creation 

Through  the  creation  of  numerous  websites,  the  developer  has  discovered  that  the 
use  of  web  templates  is  highly  desirable  for  the  creation  of  sites  larger  than  a  few  pages. 
A  web  template  is  used  in  the  development  environment  as  a  starting  point  for  the 
creation  of  new  pages.  Essentially,  it  gives  all  the  pages  the  same  look  and  functionality. 
In  addition  is  provides  the  capability  to  update  multiple  pages  at  once  in  the  future  simply 
by  changing  the  template.  The  template  will  address  the  issue  of  providing  a  common 
menu  structure  throughout  the  site. 

a.  Format  and  Style 

An  initial  requirement  for  the  portal  is  a  user-friendly  interface  for  the 
portal.  User  friendly  is  a  vague  term,  but  primarily  incorporates  two  specific  issues:  ease 
of  navigation  and  an  aesthetically  pleasing  site.  Three  simple  points  can  be  used  when 
developing  a  site  contrast,  readability,  and  accessibility.  With  these  points  in  mind,  a 
successful  user  interface  should  be  attainable. 

Contrast  refers  to  the  proper  use  of  colors  for  delivery  of  information  and 
site  creation.  This  goal  is  accomplished  by  using  colors  that  complement  each  other 
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without  being  hard  to  distinguish.  The  easiest  example  of  this  is  not  to  use  a  dark  eolor 
on  a  dark  eolor  baekground  (i.e.  dark  blue  does  not  stand  out  on  a  black  background. 
Figure  14  shows  an  example  of  good  contrast  next  to  a  bad  example.  The  color  scheme 
for  this  project  was  chosen  using  the  Civil  Engineer  Corps  logo  and  The  Fighting  Seabee. 
The  resulting  color  pallet  is  shown  in  Figure  15. 


Good  Example 


Bad  Example 


Figure  14.  Web  Contrast  Example 


Figure  15.  CEC  Portal  Palette 

Readability  has  a  two-fold  criterion.  The  first  of  these  is  to  ensure  the  size 
and  font  selected  for  text  to  be  displayed  on  the  site  is  easy  for  users  to  see  and  read.  The 
second  half  of  the  criteria  deals  with  the  delivery  of  information  in  an  efficient  manner. 
Users  should  not  have  to  scroll  anymore  than  necessary,  and  vertical  scrolling  is  typically 
more  desirable  than  horizontal  scrolling.  Several  things  go  into  the  attainment  of  this 
goal  including  font  selection,  page  layout,  monitor  size,  and  resolution.  For  this  project, 
a  standard  web  font  set  in  Dreamweaver  will  be  used.  The  font  set  includes  Arial, 
Helvetica,  and  San-Serif  These  fonts  are  simple  and  easy  to  read  and  are  available  on 
most  systems  in  their  standard  configuration.  The  font  set  uses  the  first  font  if  available 
on  the  system,  or  it  works  through  the  list  until  it  finds  one  of  the  fonts  for  use  on  the  site. 
The  fonts  are  similar.  This  ensures  that  most  users  will  see  the  page  as  the  developer 
intended.  Page  layout  is  critical  to  the  success  of  this  goal.  If  a  page  is  too  graphic 
intensive,  it  will  not  have  room  for  text  that  needs  to  be  delivered.  If  the  page  has  a  lot  of 
“white  space,”  the  content  will  not  fill  up  the  page,  and  it  will  look  void  of  information. 

Concerning  monitor  size  and  screen  resolution,  these  vary  greatly  from  location  to 
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location.  No  one  size  can  be  counted  on  for  all  users,  but  it  has  been  established,  through 
conversations  with  numerous  end  users,  that  1024  x  768  is  a  safe  resolution  to  design  for 
in  most  modern  systems.  There  will  be  exceptions  in  both  directions.  Some  users  will 
have  to  scroll  to  see  all  content,  and  others  will  have  too  mueh  “white  space”  on  their 
page.  This  can  be  avoided  by  developing  the  site  in  two  or  three  sizes,  detecting  the 
elient  resolution  when  the  user  aecesses  the  site,  and  direeting  them  to  the  appropriate  site 
developed  for  their  resolution.  This  is  very  intensive  and  will  not  be  done  for  this 
prototype  ereation. 

Aecessibility  is  also  important  to  the  suceessful  design  of  a  website. 
Again,  there  are  two  aspeets  to  this  eriterion.  The  first  is  providing  common  user  access 
to  all  information  on  the  site  in  an  easy  to  loeate  format.  These  issues  will  be  addressed 
in  the  following  section.  The  second  is  accessibility  for  disabled  persons  as  required  by 
Section  508.  This  issue  will  also  be  addressed  in  a  follow-on  section. 

b.  Menus 

The  eommon  menu  strueture  of  the  site  is  eritical  to  providing  users  with  a 
positive  experienee  when  visiting  a  site.  The  menu  system  is  the  core  of  the  web 
template  to  be  created  for  the  site.  By  using  a  eommon  menu  throughout  the  portal,  users 
can  quickly  identify  and  find  their  way  around  the  site.  The  menu  items  to  be  used  for 
this  project  are  Home,  News,  Awards,  Orders,  Links,  and  Searehes.  These  links  give 
aceess  to  all  of  the  resources  on  the  site  from  all  pages  in  the  site.  Appendix  E  shows  the 
detailed  site  plan  and  how  the  menu  structure  works  within  the  site  for  navigation. 

c.  Section  508  Requirements 

“Seetion  508  requires  that  Federal  ageneies'  electronie  and  information 
technology  is  accessible  to  people  with  disabilities.”  (Section  508,  2002)  In  light  of  these 
requirements,  research  was  completed  to  identify  a  list  of  requirements  mandated  by  this 
regulation.  Appendix  F  provides  a  quick  list  identified  by  the  web  center  @  NIEHS 
(National  Institute  of  Environmental  Health  Seienees).  The  template  for  this  portal  was 
ereated  with  these  requirements  in  mind.  Most  of  the  requirements  have  been  met, 
ineluding  one  of  the  most  obvious,  whieh  is  the  identification  of  graphical  objects  using 
the  HTML  ALT  tag.  This  tag  displays  a  pop-up  text  box  for  all  graphical  elements  on  the 
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page.  In  addition,  all  information  links  presented  using  eolor  were  duplieated  using  text 
indication  such  as  underlining. 

A  detailed  analysis  of  the  site  would  be  required  to  ensure  that  all 
requirements  were  met.  This  investment  of  time  is  unnecessary  at  this  point  because  this 
is  strictly  a  prototype  development. 

7.  Home  Page  Functionality 

The  primary  function  of  the  homepage  is  to  act  as  a  central  point  for  the  entire 
portal.  In  addition,  the  most  recent  news,  awards,  and  orders  releases  will  be  displayed. 
The  page  is  designed  with  the  menu  system  on  the  right,  a  central  information  delivery 
section  in  the  center,  and  quick  access  to  information  discussed  in  the  next  three  sections. 
Figure  16  is  a  screen  capture  of  the  home  page. 

The  News  and  Awards  sections  list  the  two  most  current  records.  The  orders 
section  shows  the  most  recent  20  sets  of  orders  released.  All  other  news,  awards,  and 
orders  are  provided  in  Phase  III,  IV,  &  V.  Additional  functionality  of  the  home  page 
includes  identification  of  the  member  currently  logged  into  the  system. 
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Civil  Engineer  Corp&^ormonon  Delivery  Portal 


Welcome  NEIL  RADER 

Last  name  quick  search 


There  are  currently  1312  members 
with  no  e-mail  address  in  the 
database 

_ ...see  the  list 


Figure  16.  Portal  Flome  Page 


8,  Quick  Member  Search 

One  of  the  most  useful  functions  provided  by  this  portal  is  the  quick  location  of 
addresses,  phone  numbers,  and  e-mail  addresses  of  other  community  members.  With  this 
in  mind,  a  quick  member  search  was  added  to  the  home  page.  Members  can  search  using 
any  portion  of  a  person’s  last  name.  Upon  submission  of  the  request,  the  user  is 
presented  with  a  list  of  members  meeting  the  search  criteria.  An  example  of  the  results 
page  is  shown  in  Figure  17.  From  the  list  of  members,  the  user  can  choose  to  see  the 
detailed  record  of  the  member.  The  detailed  record  contains  all  addresses,  phone 
numbers,  and  e-mail  addresses  that  the  member  has  listed  in  the  system.  This  page  is 
shown  in  Figure  18. 
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Member  Search  Results 


Rank 

Name 

Year 

Group 

Desig. 

Current  Activity 

Detailed 

Record 

CAPT 

KING,  DANIEL  P 

1930 

5100 

COMNAVFACENGCOMHQ  WASH  DC 

...GO 

LCDR 

KING.  DOUGLAS  W 

1983 

5105 

PWC  WASHINGTON  DC 

...GO 

CAPT 

KING,  ROBERT  H 

1978 

5100 

CiNCPAC  PEARL  HARBOR  HI 

...GO 

LT 

KING,  SCOTT  R 

1995 

5100 

..GO 

CW02 

STONEKING,  TERRANCE  ALBIN 

1990 

7531 

...GO 

Records  1  to  5  of  5 

Figure  17.  Member  Search  Results  Page 

View  LT  NEIL  RADER's  Information 
Current  Assignment 


STUDENT  AT  NPS  STUDENTS  MONTEREY  CA 


E-Mail  Addresses 

Phone 

Numbers 

Type 

Address 

Type 

Number 

WORK 

ncraderiertDS  .na  vv.  mi  1 

HOME 

1-831-3944031  X 

HOME 

ncraderlS'msn.com 

WORK 

1-831-6562911  X 

HOME 

ncraderi^otmail  com 

MOBILE 

1-831-2772298  X 

OTHER 

ncraderiQI  vcos  .com 

DSN 

8782911 

Addresses 

Type 

Street 

City 

state 

Zip 

Country 

HOME 

220  TUNISIA  ROAD 

SEASIDE 

CA 

93955 

UNITED  STATES 

WORK 

1  UNIVERSITY  CIRCLE 

MONTEREY 

CA 

93943 

UNITED  STATES 

Figure  18.  Member  Detail  Page 
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7. 


Missing  E-mail  Notification 


One  of  the  primary  methods  of  communication  between  CEC  community 
managers  and  community  members  is  using  e-mail.  Because  of  this,  it  is  very  important 
that  all  members  maintain  an  active  e-mail  address  in  the  system.  The  home  page 
displays  the  current  number  of  members  who  have  no  e-mail  in  the  system.  This  count  is 
provided  by  using  a  SQL  COUNT  statement  to  count  members  not  contained  in  the 
EMAIL  entity.  Directly  under  the  count  is  a  link,  which  takes  the  member  to  a  list  of  all 
members  with  no  address  in  the  system.  Erom  this  second  page,  the  member  can  choose 
to  submit  a  link,  if  they  are  on  the  “guilty”  list. 

8,  Member  Record  Updates 

A  final  resource  accessible  directly  from  the  home  page  is  a  link  to  the  member 
update  section  of  the  site.  After  following  this  link,  the  member  is  presented  with  a 
member  detail  page  of  his  or  her  own  personal  information.  This  page  is  similar  to  the 
member  details  page  accessible  from  the  quick  search  function,  but  with  the  addition  of 
edit,  add,  and  delete  links.  These  differences  in  this  page  can  be  seen  in  Eigure  19. 


View  LT  NEIL  RADER’S  Member  Record 

Current  Assignment 

STUDENT  AT  NPS  STUDENTS  MONTEREY  CA 


E-Mail  Addresses 

..submit  a  newaddress 

Phone  Numbers 

submit  a  newnumber 

Type 

Address 

Edit/Delete 

Type 

Number 

Edit/Delete 

WORK 

ncraderigrips  .navy,  mil 

edit  /  delete 

HOME 

1-831-3S44031  X 

edit  /  delete 

HOME 

ncradengimsn.com 

edit  /  delete 

WORK 

1-831-6662911  X 

edit  /  del ete 

HOME 

ncrader@hot mail  .com 

edit  /  delete 

MOBILE 

1-83 1-2772298  X 

edit  /  del  ete 

OTHER 

ncradengil  ycos  .com 

edit  /  delete 

DSN 

8782911 

edit  /  delete 

Addresses 

..  submit  a  ne'w  address 

Type 

Street 

City 

State 

Zip 

Country 

Eciit/Delete 

HOME 

220  TUNISIA  ROAD 

SEASIDE 

CA 

93955 

UNITED  STATES 

edit  /  delete 

WORK 

1  UNIVERSITY  CIRCLE 

MONTEREY 

CA 

33943 

UNITED  STATES 

edit  /  delete 

Eigure  19.  Member  Update  Page 

This  section  takes  advantage  of  the  session  variables  discussed  earlier.  When  a 
member  clicks  the  link  to  update  member  records,  the  site  uses  the  current  username  to 
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identify  the  reeord  to  display  and  allow  update  aecess.  In  other  words,  when  users  elick 
on  this  link,  they  will  only  see  their  own  information  beeause  they  are  identified  by  their 
login  name.  Sample  add,  edit,  and  delete  web  forms  are  provided  for  address 
information.  These  are  included  in  Appendix  G.  The  forms  for  phone  numbers  and  e- 
mail  addresses  are  similar. 

G.  PHASE  3,  4,  &  5  -  INFORMATION  DELIVERY  CAPABILITES 

These  phases  are  combined  for  documentation  purposes  because  their  scope  is 
limited  and  some  of  the  functionality  has  already  been  provided  in  the  previous  phase. 
The  home  page  provides  quick  access  to  recent  news,  awards,  and  orders  release.  In 
addition,  the  home  page  provides  access  to  simple  member  searches,  and  user  record 
updates.  Having  provided  these  capabilities  directly  from  the  home  page  reduces  the 
work  required  in  these  last  3  phases. 

1.  Phase  3  -  Personnel  information  delivery 

The  requirements  for  this  phase  include: 

•  Allow  activity  searches 

•  Provide  detailed  activity  search  results 

•  Allow  member  searches 

•  Provide  detailed  member  profile  search  results 

•  Allow  billet  searches 

The  member  search  capability  and  detailed  member  profile  viewing  have  already 
been  provided  through  the  quick  last  name  search  for  members  on  the  home  page.  This 
capability,  although  very  useful,  is  limited.  The  search  by  last  name  requires  more 
information  than  some  users  may  have.  A  user  may  wish  to  search  using  multiple  criteria 
values  such  as  rank  and  year  group.  The  idea  is  to  provide  as  much  capability  as 
possible.  Figure  20  shows  the  advanced  member  search  portion  of  the  searches  page. 
The  values  included  in  the  search  capability  are  first  name,  last  name,  rank,  designator, 
and  year  group.  The  member  can  enter  all  or  none  of  these  values  to  be  part  of  the  search 
string.  The  results  for  this  search  are  displayed  in  the  same  format  as  the  quick  member 
search  previously  identified  and  displayed  in  Figure  18. 
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Member  Search 


First  Name 
Last  Name 
Rank 
Designator 
Year  Group 


ADM 

3 

5100 

V 

1 

J 

^ 

Search 

\ 


Figure  20.  Advanced  Member  Search  Web  Form 

Activity  searches  are  also  a  required  capability  for  the  portal.  This  capability  has 
been  added  using  the  following  method.  A  user  chooses  a  CEC  Region  to  search  in  using 
a  provided  list  of  options.  This  portion  of  the  advanced  searches  page  is  also  shown  in 
Figure  21.  This  search  is  submitted  and  the  user  is  presented  with  a  list  of  all  activities  in 
that  region.  A  results  page  is  shown  in  Figure  22.  The  user  can  then  select  an  activity 
from  the  list  and  will  be  provide  with  a  detailed  report  for  that  activity  consisting  of  the 
address,  phone  numbers,  and  all  members  currently  assigned  to  billets  at  that  command. 
A  screen  capture  of  the  results  for  Naval  Facilities  Engineering  Command  is  included  in 
Eigure  23. 


Activity  Search 


Region 


Naval  District  Washington 


f  S 

Search 


Eigure  2 1 .  Activity  Search  Web  Form 
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Activity  Search  Resuits  for  EFA  SOUTHEAST 


Name 

UIC 

City 

State 

Country 

PWC  JACKSONVILLE  FL 

68931 

JACKSONVILLE 

FL 

UNITED  STATES 

ill  -i.CA  ■  OUTHEAST  JACKSONN  1. 

44226 

JACKSONVILLE 

FL 

UNITED  STATES 

NAS  JACKSONVILLE  FL 

00207 

JACKSONVILLE 

FL 

UNITED  STATES 

NAVSPTEL  BICMD  JACKSONVILLE  FL 

32264 

JACKSONVILLE 

FL 

UNITED  STATES 

NAVHOSP  JACKSONVILLE  FL 

00232 

JACKSONVILLE 

FL 

UNITED  STATES 

NAVAVNDEPOT  JACKSONVILLE  FL 

65886 

JACKSONVILLE 

FL 

UNITED  STATES 

HLTHCARE  SUPPO  JACKSONVILLE  FL 

68907 

JACKSONVILLE 

FL 

UNITED  STATES 

COMNAVREG  SE  JACKSONVILLE  FL 

09697 

JACKSONVILLE 

FL 

UNITED  STATES 

CBU  FOUR  ONE  ZERO  JACKSONVILLE  FL 

66671 

JACKSONVILLE 

FL 

UNITED  STATES 

NAS  MAYPORT  FL 

68709 

MAYPORT 

FL 

UNITED  STATES 

NAVSTA  MAYPORT  FL 

60201 

MAYPORT 

FL 

UNITED  STATES 

CBU  FOUR  TWO  ZERO  MAYPORT  FL 

55162 

MAYPORT 

FL 

UNITED  STATES 

NAVSUBASE  KINGS  BAY  GA 

42237 

KINGS  BAY 

GA 

UNITED  STATES 

EFA  SE  CONT  OFC  KINGS  BAY  GA 

68248 

KINGS  BAY 

GA 

UNITED  STATES 

SWFLNTKN6S  BAY  GA 

68733 

KINGS  BAY 

GA 

UNITED  STATES 

CBU  FOUR  ONE  TWO  KINGS  BAY  GA 

66672 

KINGS  BAY 

GA 

UNITED  STATES 

Figure  22.  Activity  Search  Results  Page 
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Details  for  COMNAVFACENGCOMHQ  WASH  DC 


Address  10  Digit  Code:  3361002000 

COMMANDER 

NAVAL  FACILITIES  ENGINEERING  COMMAND 
1322  PATTERSON  AVENUE  SE,  SUITE  1000 

WASHINGTON  NAVY  YARD  DC  20374-5065 


Phone  Numbers 
Type 

COMMERCIAL 

DSN 

FAX 


Billets 

BSC 

Description 

Rank 

Desig 

Currently  Assigned 

01010 

PAP  CHIEF/COMNAVFACENGCOM/CHClVENG 

VAOM 

5100 

RADM  MICHAEL  JOHNSON 

01040 

PAP  CHIEFA^ICE  COMMANDER-09 

RDML 

5100 

RADM  MICHAEL  LOOSE 

03110 

FACPLN  A  PGM/DEP  CDR  ENG  OPS 

RDML 

5100 

CAPT  THOMAS  BOOTHE 

04010 

FAC  ENG/DIR  NAVY  PUB  WORKS 

CAPT 

5100 

CAPT  ARTHUR  AYARS 

01110 

IG/ADDU  TO  91180/47326 

CAPT 

5100 

CAPT  RAYMOND  MELLO 

01310 

PERS  PAP  CHIEF/DIR  SEABEE  READINESS 

CAPT 

5100 

CAPT  JOHN  SURASH 

02010 

FACPLN  A  PGM/DIR  HOUSING 

CAPT 

5100 

CAPT  THOMAS  LIEDKE 

03130 

FACPLN  A  PGM/DIR  CIO 

CAPT 

5100 

CAPT  DANIEL  KING 

05210 

FAC  ENG/ASST  CDR  PGM  COORD 

CAPT 

5100 

CAPT  ANDREW  BRUNHART 

05110 

FAC  ENG/ASST  COR  ENG  RESRCES 

CAPT 

5100 

CAPT  ERNEST  KATZWINKEL 

04610 

FACPLN  A  PGM/DIR  ENG  OPS 

CAPT 

5100 

CDR  JAMES  JACKSON 

04010 

FAC  ENG/DIR  NAVY  PUB  WORKS 

CAPT 

5100 

CAPT  WILLIAM  BEARY 

01030 

EXEC  ASST  TO  CDR-OOB 

CDR 

5100 

LCDR  JOHN  KORKA 

03190 

FACPLN  A  PGM/HD  CSSO 

CDR 

5100 

CAPT  PHILIP  DALBY 

03220 

FACPLN  A  PGM/ASST  DIR  FLD  OPS 

CDR 

5100 

CAPT  THOMAS  CALHOUN 

04630 

FACPLN  A  PGM/ASST  DIR  BUS  ASSMT 

CDR 

5100 

CDR  SUSAN  GLOBOKAR 

05320 

FAC  ENG/HD  PW  ADVOCACY 

CDR 

5100 

CDR  CAMERON  MANNING 

06070 

FAC  ENG/DIR  SEABEE  DOCTRINE 

CDR 

5100 

LCDR  DENNIS  DUREN 

06070 

FAC  EN6/D1R  SEABEE  DOCTRINE 

CDR 

5100 

CDR  VINCENT  RACANELLI 

06090 

FAC  ENG/HD  HSG  PPV  COORD  OFF 

CDR 

5100 

CDR  MICHAEL  STOLL 

04320 

FACPLN  A  PGM/FLD  OPS  PGM  OFF  PAC 

LCDR 

5100 

LTROLFE  ASHWORTH 

06020 

FAC  ENG/BRAC  POLICY  MGR 

LCDR 

5100 

LTTUAN  NGUYEN 

02030 

FACPLN  A  PGM/FLD  OPS  PGM  OFF  LANT 

LCDR 

5100 

LCDR  MICHAEL  ARMES 

01651 

FAC  RSCH/NCF  PGM  OFF/DVG  GEN 

LCDR 

5100 

LT  MICHAEL  TEATES 

01630 

EXEC  ASST/CDR  CONT  ENG  GRP 

LCDR 

5100 

LCDR  KEVIN  HUTSELL 

Figure  23.  Activity  Detail  Page 


Number 

1-202-6859000 
3259000 
1  •202-685 1463 
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The  final  type  of  search  required  is  a  type  of  billet  search  capability.  This 
functionality  is  intended  to  allow  members  to  search  for  jobs  in  billets  having  their  rank 
opening  up  during  the  month  and  year  that  they  plan  to  rotate.  To  do  this  the  user  enters 
his  or  her  rank  chosen  from  a  list  of  allowable  values  and  enters  the  two  digit  month  and 
four  digit  year  in  which  they  wish  to  search.  The  billet  search  portion  of  the  searches 
page  is  shown  in  Figure  24.  The  results  provide  a  list  of  billets  and  their  associated 
activities.  A  Results  page  can  be  seen  in  Figure  25. 


Billet  Search 


Rank 


ADM 


Date 


MM 


YYYY 


Search 


Figure  24.  Billet  Search  Web  Form 


Billet  Search  Results  for  8-2003 


Description 

Activity 

Rank 

Desig 

Encumbent 

PW  OPS/ASST  DIR 

NAVSTA  ROOSEVELT  ROADS  PR 

LT 

5100 

LT  KEITH  MIERTSCHIN 

CIV  AFF/AOIC 

COMUSNAVSO  CIVIC  ACTION  DET  ROOSEVELT 
ROADS  PR 

LT 

5100 

LCDR  CARMELO  MELENDEZ 

FAC  CONST/SVC/AROICC 

ENGFLDACTMED  SICILY  ITALY 

LT 

5100 

LT  LEAF  BALLAST 

FAC  CONST/SVC/AROICC 

ROICC  MID-PACIFIC  PEARL  HARBOR  HI 

LT 

5100 

LT  DONALD  BRUS 

FAC  CONST/SVC/AROICC 

ROICC  MID-PACIFIC  PEARL  HARBOR  HI 

LT 

5100 

LT  JAY  MURPHY 

PWO  (ASSISTANT) 

COMNAVACT  LONDON  UK 

LT 

5100 

LT  RYAN  TIBBETTS 

PW  OPS/UTILITIES  OPS  OFF 

PWC  PEARL  HARBOR  HI 

LT 

6530 

LT  DAVID  MCALISTER 

P  WO/AD  DU  TO  17005/68442 

NAVHOSP  NAPLES  ITALY 

LT 

5100 

LTJG  NEIL  WEST 

Figure  25.  Billet  Search  Results  Page 
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2,  Phase  4  -  Professional  information  delivery 

Professional  information  is  limited  to  four  categories  four  this  prototype:  Seabees, 
Public  Works,  Acquisitions,  and  General.  Providing  access  to  information  in  these 
categories  is  the  driving  requirement  for  this  phase.  This  information  is  stored  in  the 
form  of  links  to  external  sites.  When  a  link  is  chosen,  the  user  is  taken  to  the  external  site 
to  view  the  relevant  information.  This  method  was  chosen  for  display  of  professional 
information  because  the  task  of  maintaining  all  of  the  information  at  this  one  site  is 
insurmountable  and  unnecessary.  Since  most  of  the  resources  needed  by  CEC  officers 
for  professional  development  are  available  somewhere  on  the  web,  the  external  links 
were  used.  The  links  page  is  shown  in  Figure  26. 

Community  Information  Resources 

Seabee  Links  Acquisition  Links 

CORRESPONDENCE  COURSES  0  @  NAW  ACQUISITION  &  BUSINESS  0  @ 


Public  Works  Links  General  Links 

CECOS  0  @  PROFESSIONAL  REGISTRATION  -  INFO  BY  STATE  0  @ 


Figure  26.  Information  Resource  Finks  Page 

3,  Phase  5  -  Community  items  of  interest  delivery 

This  final  phase  of  development  is  provided  for  the  development  of  the  delivery 
pages  for  news,  awards,  and  orders  releases.  As  was  previously  identified  in  the  home 
page  development  phase,  these  pieces  of  information  are  delivered  in  limited  quantity  on 
the  home  page.  The  detailed  news,  awards,  and  orders  pages  are  used  to  grant  access  to 
all  current  information.  The  news  and  awards  pages  deliver  information  in  sets  of  five. 
The  orders  page  delivers  information  in  sets  of  twenty.  The  user  can  navigate  through  the 
records  using  the  recordset  navigation  menu  at  the  bottom  of  these  pages.  Examples  of 
each  of  these  pages  are  provided  in  Appendix  H. 
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H.  COMPLETION,  TESTING,  AND  TROUBLESHOOTING 

With  all  phases  of  development  eomplete,  final  issues  regarding  completion  of  the 
site  can  be  discussed.  Essentially  every  detail  of  functionality  provided  by  the  site  has 
been  detailed  in  the  previous  sections.  However,  one  item  remains.  Interlinking 
capability  has  been  provided  throughout  the  site.  This  capability  allows  a  user  to  search 
for  a  member  and  then  click  on  the  activity  that  the  member  is  stationed  at  and  be 
directed  to  that  activities  detail  page.  The  same  is  true  for  selecting  member  links  on  the 
activity  pages.  These  direct  the  user  to  the  member  detail  page.  In  addition,  e-mail  links 
on  member  detail  pages  are  hyperlinks  to  call  up  the  mailto  function  and  call  up  the 
user’s  default  e-mail  program  with  an  e-mail  to  the  selected  member. 

Like  rapid  application  development,  testing  and  troubleshooting  are  an  iterative 
process.  Although  testing  was  done  throughout  the  duration  of  the  development  phases,  a 
true  test  of  the  web  portal  and  its  interoperability  with  the  database  could  not  be 
performed  until  the  database  and  portal  were  at  a  high  percentage  of  completion.  The 
remaining  work  involved  in  the  development  was  an  iterative  use  and  troubleshoot 
method.  The  developer  and  other  selected  users  accessed  the  portal  and  looked  for  errors, 
formatting  issues,  and  other  problems  not  yet  identified.  No  major  problems  were  found, 
but  minor  corrections  to  database  web  queries  were  made  and  some  formatting 
adjustments  were  made  to  the  site. 

This  concludes  the  development  portion  of  the  project.  A  CD-ROM  containing 
the  database  and  the  entire  web  application  is  included  in  Appendix  I.  Chapter  4 
addresses  issues  associated  with  the  implementation  of  this  or  some  similar  concept  for 
use  by  the  community. 
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IV.  PROJECT  IMPLEMENTATION 


The  prototype  portal  and  supporting  database  are  eomplete,  and  the  issue  of 
implementation  must  be  diseussed.  This  project  was  undertaken  as  a  proof-of-concept  to 
show  that  an  information  delivery  tool  such  as  a  portal  could  be  used  to  provide  the  Civil 
Engineer  Corps  with  a  wide  variety  of  resources  online.  Providing  a  portal  similar  in 
concept  to  the  one  developed  in  this  project  would  give  members  of  the  community 
access  to  the  information  it  contains  from  any  location  with  internet  access.  Portions  of 
this  project  are  usable  as  delivered  in  this  prototype;  however,  others  are  not.  In  order  to 
implement  a  similar  working  concept,  several  issues  must  be  addressed.  Currently,  there 
is  no  plan  to  implement  this  system,  but  the  intent  of  the  developer  is  to  provide  a  quality 
concept  that  will  generate  interest  in  pursuing  a  production  model.  In  order  for  this  to 
become  a  reality  the  items  discussed  in  this  chapter  must  first  be  considered. 

A.  ARCHITECTURE 

The  first  issue  to  be  addressed  is  the  architecture  to  be  used  for  hosting  the 
database  and  the  web  portal.  Two  and  three  tier  alternatives  are  to  be  considered.  The 
current  prototype  utilizes  a  two  tier  architecture  for  the  portal-database  interaction,  and 
single  tier  for  the  data  management  forms  created  in  Access.  The  current  implementation 
is  not  ideal  for  a  working  implementation. 

1.  Two  Tier 


A  traditional  two  tier  front  end  consists  of  a  server  and  a  client.  Figure  27  shows 
a  graphical  representation  of  this  model. 


Figure  27.  Two  Tier  Architecture 
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The  database  is  stored  and  managed  on  the  server,  whieh  also  hosts  the  website. 
The  user  interface  or  front  end  is  provided  to  the  client  either  through  a  desktop 
application  and/or  website.  The  client  makes  requests  to  the  server.  On  the  server  side,  a 
desktop  application  would  interact  directly  with  the  DBMS.  In  addition,  a  web  interface 
would  connect  directly  to  the  web  server  which  would  communicate  with  the  DBMS  on 
the  same  server. 

2,  Three  Tier 

The  three  tier  architecture  model  provides  for  the  separation  of  user,  application, 
and  data.  Figure  28  shows  the  interaction  between  the  tiers  in  this  model. 


Figure  28.  Three  Tier  Architecture 

This  structure  is  typically  used  in  web-based  applications.  The  user  accesses  the 
system  through  the  client  machine  (i.e.  a  portal),  the  application  or  web  server  receives 
the  requests  and  forwards  them  onto  the  database  server,  which  in  turns  fulfills  the 
request  and  returns  the  requested  information  to  the  client  via  the  web  server.  This  model 
is  advantageous  in  that  it  separates  the  data  from  the  application,  which  makes  the 
information  more  secured. 

3.  Selection 

The  architecture  used  for  the  prototype  is  sufficient  for  that  purpose,  but  an 
implemented  solution  would  need  to  be  more  robust  and  allow  for  data  separation.  It  is 
recommended  that  an  end  product  would  utilize  a  three  tier  architecture  with  all  access  to 
the  data  for  users  and  managers  provided  through  the  web.  The  client  would  simply 
needed  an  internet  browser  such  as  Microsoft  Internet  Explorer,  Netscape  Navigator,  or 
Mozilla  in  order  to  access  the  resources.  The  application  server  could  be  Microsoft 
Internet  Information  Server,  ColdFusion  Server  by  Macromedia,  or  others.  Finally,  the 
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DBMS  functionality  should  be  provided  by  an  industry  standard  produet  sueh  as  Oraele 
or  SQL  Server.  This  eombination  of  produets  in  the  preseribed  arehitecture  would 
provide  a  robust  capability  with  data  integrity. 

B.  DATA  MIGRATION  &  MAINTENANCE 

There  are  several  issues  that  must  be  addressed  directly  related  to  the  data  model 
and  the  existing  data  available  for  use.  The  projeet  could  not  be  suceessful  without 
addressing  these. 

1,  Data  Migration 

As  was  discussed  in  the  database  development  section,  the  data  model  for  this 
projeet  was  not  entirely  normalized.  This  was  due  to  the  format  of  the  existing  data.  The 
data  in  its  eurrent  form  is  not  relational  database  friendly.  The  database  in  its  prototype 
form  would  require  manual  interaetion  from  the  eommunity  detailer  offiee.  The  dataset 
that  has  been  entered  into  the  funetional  prototype  would  need  to  be  verified,  updated, 
and  eompleted.  There  is  a  substantial  portion  of  the  information  missing.  This  is  due  to 
the  diffieulty  of  utilizing  the  existing  legaey  data.  Also,  a  large  portion  of  the  personnel 
information  is  not  eurrently  stored  in  any  database.  The  data  populated  in  these  entities 
was  provided  by  supporters  of  the  concept  who  are  members  of  the  eommunity.  Further 
diseussion  will  follow  on  this  subjeet  in  the  eonelusion  chapter. 

2,  Data  Maintenance 

Many  a  wise  person  has  said  that  a  database  is  only  as  good  as  its  data.  There  has 
never  been  a  greater  truth  spoken.  In  order  for  a  database  application  to  be  useful  and 
produetive,  it  must  eontain  meaningful  eurrent  data.  This  is  a  big  hurdle  for  the  proposed 
system.  The  information  with  respeet  to  activity,  billet,  and  orders  is  stored  in  a  legaey 
system  previously  discussed.  There  is  no  eurrent  method  of  integrating  the  data.  The 
system  must  be  standalone.  This  ereates  additional  work  for  the  staff  at 
NAVPERSCOM.  The  features  of  this  site  are  not  supported  direetly  by  the  Navy  at  this 
time.  However,  the  PI  is  a  eommunity  supported  item  and  will  eontinue  to  be  supported 
in  some  form.  Member  data  supported  by  this  prototype  would  be  maintained  by  the 
user.  In  order  to  make  this  effort  successful,  users  would  have  to  be  excited  about  the 
eapabilities  offered  through  this  portal.  If  eommunity  was  interested  in  the  use  of  the 
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site,  they  would  partieipate  in  properly  maintaining  their  addresses,  phone  numbers,  and 
e-mail  addresses. 

C.  SITE  MIGRATION 

In  order  to  make  use  of  the  system  developed  in  this  project,  the  portal  would 
have  to  be  migrated  to  a  permanently  supported  site  such  as  the  NAVFAC  Information 
Technology  Center  in  Port  Hueneme,  California.  Migration  of  a  site  from  one  server  to 
another  often  involves  a  certain  amount  of  troubleshooting.  This  fact  was  encountered 
when  moving  the  site  from  the  site  which  it  was  developed  on  to  the  system  where  it  is 
currently  hosted.  Issues  that  often  arise  during  migration  include  database  connectivity 
problems,  file  permission  issues,  and  web  server  configuration  conflicts.  Each  of  these 
problems  was  encountered  during  the  migration  to  the  SeabeeOne  server  that  currently 
hosts  the  site.  These  problems  are  not  insurmountable.  Rather,  they  are  things  which 
should  be  considered  if  the  portal  was  migrated  to  a  production  server. 

Since  this  portal  will  probably  not  be  implemented  in  its  current  state,  the 
migration  issues  are  not  critical.  Any  new  developments  based  on  the  prototype  could 
use  the  application  server  function  of  the  Dreamweaver  development  environment  to 
eliminate  most  of  this  problem. 

D,  USER  MANUAL  AND  TRAINING 

A  user  manual  was  not  provided  with  this  documentation  because  the  project  is 
simply  a  prototype  and  there  are  no  immediate  plans  for  implementation.  If  the  system 
was  utilized,  a  user  manual  and  training  would  need  to  be  provided,  at  a  minimum  to  the 
community  managers  who  would  be  maintaining  the  data.  Proper  use  of  the  system 
facilitated  by  proper  instruction  ensures  that  the  data  will  be  kept  in  a  proper  manner. 
The  portal  has  been  created  with  simplicity  in  mind;  therefore,  little  instruction  should  be 
required  for  members  of  the  community  who  would  be  accessing  the  site.  Also,  most 
members  of  the  community  are  familiar  with  the  internet  and  the  operation  of  typical  sites 
found  there.  This  site  follows  those  same  development  guidelines  and  should  be  very 
familiar  to  users  accessing  the  site. 
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E,  OTHER  ISSUES 

1.  Contractor  Support 

If  a  decision  is  made  to  proceed  with  this  concept,  a  choice  would  have  to  be 
made  regarding  whether  to  use  the  prototype  and  enhance  or  create  a  new  site  from 
scratch.  In  a  government  environment,  either  of  these  options  lend  themselves  to  a 
contractor  developed  and  supported  site.  Resources  are  available  through  the  NAVFAC 
CIO  office  to  support  such  an  effort.  A  contractor  could  provide  advanced  data  migration 
and  web  development  capabilities,  and  future  support  for  the  application. 

2,  NMCI 

In  order  for  this  project  to  proceed  using  the  Dreamweaver  development 
environment,  a  waiver  would  have  to  be  granted  since  it  is  not  currently  on  the  list  of 
approved  software.  Microsoft  FrontPage  is  on  the  approved  list;  however,  its  capabilities 
are  highly  limited  for  web-based  data  applications.  This  issue  could  be  moot  if  a 
contractor  was  used  for  development  and  support. 
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V.  CONCLUSION 


A,  LESSONS  LEARNED 

Throughout  the  course  of  this  project,  a  few  specific  items  have  been  identified  as 
things  to  avoid  in  future  developments  of  similar  projects.  This  section  is  not  devoted  to 
identification  of  every  mistake  made  during  the  development.  It  simply  exists  to  point 
out  key  changes  in  the  process  that  would  have  streamlined  the  development. 

1.  Data  Modeling 

The  creation  of  the  schema  is  critical  to  the  success  of  any  project  involving 
access  to  a  database.  Obtaining  a  properly  normalized  data  model  is  often  a  process  of 
trial  and  error,  but  it  must  be  done  to  the  largest  extent  possible  to  help  prevent  future 
data  errors  and  duplication.  The  lesson  learned  in  this  area  is  to  begin  the  creation  of  the 
data  model  with  a  very  open  mind.  This  is  often  difficult  to  do,  but  it  can  make  the 
creation  of  the  model  much  easier  if  it  is  accomplished.  If  the  developer  attempts  to 
create  the  model  but  has  preconceived  ideas  about  the  data  involved,  obvious 
relationships  may  be  missed. 

As  an  example,  the  relationship  between  activities  and  billets  is  considered  at  this 
time.  In  the  Civil  Engineer  Corps,  activities  have  several  billets  associated  with  them. 
Several  activities  may  have  a  Public  Works  Officer  billet;  however,  the  data  from  the 
NAVPERSCOM  legacy  system  treats  each  of  these  Public  Works  Officer  billets  as  a 
unique  billet  and  might  possibly  have  different  short  descriptions  for  the  billet.  In  a 
proper  model,  this  would  be  one  billet  at  many  activities.  In  other  words,  the  relationship 
would  be  many-to-many.  This  fact  was  overlooked  during  the  initial  creation  of  the  data 
model.  This  causes  duplication  of  data  and  inefficiency  in  the  design.  In  the  end,  this 
mistake  was  left  in  the  design  of  the  model  for  the  prototype  because  it  made  population 
of  the  database  substantially  simpler.  Without  this  allowance,  the  data  would  have 
needed  to  be  manually  scrubbed  to  find  all  billets,  which  were  actually  the  same.  This 
effort  was  more  than  allowed  for  in  the  development  of  this  system.  If  a  system  of 
similar  design  were  put  into  place,  a  decision  would  have  to  be  made  regarding  whether 
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to  continue  to  allow  the  model  irregularity  or  to  normalize  this  relationship  and  fix  the 
data. 

2.  Lookup  Confusion 

During  the  initial  ereation  of  the  database,  it  was  deeided  to  use  lookup  tables  for 
control  of  the  allowable  values  for  several  entity  attributes  such  as  types  and  eategories. 
In  the  design  of  this  portal,  data  for  addresses,  phone  numbers,  and  e-mail  addresses  are 
to  be  utilized.  The  deeision  was  made  to  use  a  lookup  table  for  the  allowable  list  of  type 
values  for  these  data  reeords.  Initially  a  single  entity  was  ereated  eontaining  all  possible 
types  for  eaeh  of  these  data  types.  Later,  it  was  diseovered  that  the  use  of  this  tables  for 
lookup  in  forms,  web  pages,  and  other  tables  would  be  eonfusing.  The  reason  for  this 
was  the  availability  of  toll-free  as  a  type  of  e-mail  in  drop-down  menu  lists  and  other 
similar  eonfusing  options.  The  eorreetion  for  this  problem  was  to  ereate  an  independent 
lookup  for  eaeh  type  of  data:  address,  phone  number,  and  e-mail  address.  A  similar 
problem  was  discovered  in  the  use  of  the  eategory  lookup  for  both  billets  and  information 
resouree  web  links.  Both  of  these  problems  were  correeted  in  order  to  eliminate  the 
eonfusion. 

3.  Web  Design 

Two  valuable  lessons  were  learned  with  respect  to  approaches  to  web  design, 
espeeially  regarding  pages  eontaining  dynamie  eontent.  The  first  of  these  is  related  to  the 
use  of  web  templates  for  the  creation  of  a  site.  A  template  ean  be  a  curse  and  a  blessing. 
The  eonvenienee  of  a  template  is  that  it  allows  you  to  create  multiple  pages  with  identieal 
eontent  on  some  portion  of  the  page.  This  is  speeifieally  useful  for  ereating  a  eommon 
navigation  or  menu  system  for  the  site. 

The  first  primary  lesson  identified  in  this  section  is  the  importanee  of  perfeeting 
the  template  before  the  ereation  of  additional  pages.  The  reason  for  this  is  the  need  for 
template  updates.  If  the  template  is  ehanged  after  the  ereation  of  other  pages,  the 
development  environment  is  able  to  update  the  additional  pages  that  have  been  ereated 
based  on  the  modified  template.  However,  these  updates  are  not  always  entirely 
sueeessful.  Speeifieally,  the  use  of  eertain  automated  server  behaviors  and  custom  scripts 
may  fail.  These  items  sometimes  prevent  the  proper  update  of  the  subsequent  pages. 
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When  this  happens,  the  additional  pages  must  be  fixed  one  at  a  time.  This  problem  was 
experieneed  late  in  the  development  of  this  prototype  when  the  logout  functionality  was 
to  be  added  to  all  pages  throughout  the  site.  The  template  was  updated  with  a  link  and  an 
automated  logout  script  created  by  Dreamweaver  UltraDev.  The  update  to  all  pages  in 
the  site  was  successful,  or  so  it  seemed.  Upon  further  inspection  and  testing  of  pages 
throughout  the  site,  it  was  discovered  that  many  pages  had  a  script  error  caused  by  the 
logout  addition.  This  error,  if  identified  early  in  the  development,  could  have  been  dealt 
with.  In  the  end,  this  behavior  was  removed  from  every  page  except  the  homepage, 
which  was  not  based  on  the  template.  Therefore,  users  must  either  close  their  browser  or 
return  to  the  homepage  in  order  to  properly  logout  of  the  site  and  clear  their  session 
variables. 

The  second  web  design  lesson  learned  is  to  plan  a  page  thoroughly  before 
attempting  to  build  it.  Sketch  the  page,  think  it  over,  re-sketch  it,  and  repeat  until  there  is 
a  high  level  of  comfort  with  the  design  of  the  page  and  the  information  to  be  delivered.  If 
this  is  done,  it  will  prevent  the  need  to  recreate  the  page  from  scratch  several  times  in 
order  to  obtain  the  desired  result.  This  method  can  be  extended  throughout  the  site  by 
sharing  page  designs  in  the  creation  of  future  pages  with  similar  data  reporting 
requirements.  This  is  similar  to  the  use  of  the  template  but  in  greater  detail. 

B.  FUTURE  WORK 

As  this  project  comes  to  completion,  it  is  clear  that  the  concept  has  been  proven, 
but  it  is  not  yet  ready  for  use  by  the  community.  There  are  several  reasons  for  this.  This 
section  provides  specific  areas  that  should  be  addressed  in  future  work  to  make  this 
prototype  more  suited  for  a  production  system. 

1.  Data  Standardization  and  Validation 

An  effort  was  made,  during  the  creation  of  the  data  model,  to  restrict  the  users 
input  of  data  wherever  possible.  The  use  of  lookup  tables  and  controlled  domains  were 
the  primary  method  by  which  this  was  accomplished.  Most  data  that  could  be 
constrained  was;  however,  there  are  a  few  other  areas  where  this  capability  could  be 
provided.  Specifically,  the  use  of  a  lookup  table  for  the  country  code  prefix  for  phone 
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numbers  and  the  country  name  for  addresses  could  be  standardized.  This  list  would  have 
to  manually  generated  or  obtained  from  other  source. 

The  method  by  which  to  store  phone  numbers  was  a  struggle  for  the  developer. 
The  existence  of  activities  and  billets  in  many  other  countries  suggests  that  several 
different  formats  could  be  used.  This  issue  could  be  evaluated  further  in  order  to  identify 
a  more  consistent  format  for  the  storage  of  these  numbers. 

Additionally  a  primary  area  in  which  functionality  was  not  provided  is  data 
validation.  The  Microsoft  Access  database  forms  have  built  in  validation.  They  will  not 
allow  a  record  to  be  created  if  a  required  value  is  null.  Although  the  program  provides 
messages  to  indicate  which  required  fields  were  not  populated,  it  would  be  beneficial  to 
designate  theses  fields  on  the  form  so  that  the  user  would  not  receive  an  error  message 
from  the  system.  Web  form  validation  was  not  provided  due  to  time  constraints.  The 
concept  is  simple.  The  application  server  checks  to  see  if  all  required  values  are  entered 
before  submitted  the  information  to  the  database.  If  fields  are  left  null,  the  client  should 
identify  to  the  user  that  certain  fields  must  be  completed.  Web  pages  would  also  benefit 
from  clear  identification  of  required  fields.  Specific  formats  for  data  to  be  entered  into 
web  forms  could  also  be  indicated  on  the  page.  This  would  help  prevent  database 
corruption  caused  by  incorrectly  formatted  data. 

2,  Fine  Tuning 

Both  the  Access  database  forms  and  the  web  pages  could  greatly  benefit  from 
additional  “fine-tuning”  before  this  system  was  made  accessible  for  use  by  the  entire 
community.  All  forms  and  pages  should  be  scrubbed  to  ensure  that  data  display  fields 
and  lookup  menus  are  sized  properly  to  view  all  data  in  the  field.  This  is  a  simple  task 
and  was  partly  completed  during  the  creation  of  this  project,  but  not  thoroughly  tested 
with  the  data  set  populated.  One  specific  area  suggested  for  improvement  of  the  web 
portal  is  the  elimination  of  scrolling  wherever  possible.  The  site  was  designed  for  1024  x 
768  resolution,  which  is  available  and  used  on  many  DoD  computers.  The  development 
process  was  a  learning  experience  for  this  project.  The  web  template  was  created  using 
certain  sizes  for  HTML  content  tables.  These  tables  often  cause  pages  to  show  a  scroll 
bar  when  there  is  no  information  stored  off  screen.  The  other  cause  for  scrolling  is  the 
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delivery  of  too  rnueh  dynamic  content  to  a  single  formatted  page.  For  example,  the  home 
page  delivers  the  two  newest  awards  and  news  stories  along  with  the  20  newest  sets  of 
orders.  This  information  typically  causes  the  page  to  scroll  because  of  the  quantity  of 
information  delivered.  This  type  of  behavior  could  be  evaluated  throughout  the  site  and 
eliminated  where  possible  and  desired.  The  elimination  of  all  scrolling  within  the  site 
makes  the  site  much  more  usable  for  the  fast-paced  users  that  are  typically  accessing  the 
web.  Users  want  information  quickly,  and  they  do  not  want  to  be  required  to  do  a  lot  of 
“clicking”  to  get  it. 

3.  Web  Functionality 

Additional  functionality  could  be  added  to  the  portal  in  the  form  of  award  and 
news  submissions,  or  additional  interactive  or  drilldown- type  search  capabilities.  The 
“items  of  interest”  submissions  were  originally  intended  as  part  of  this  project  but  were 
eliminated  due  to  time  constraints.  The  system  in  its  current  state  can  only  accept  these 
submissions  through  the  data  management  forms  in  Access.  These  submissions  would  be 
critical  to  the  success  of  a  production  site.  The  variety  of  searches  on  members, 
activities,  and  billets  is  nearly  endless.  The  community  could  be  polled  for  additional 
capabilities  that  they  would  be  interested  in  seeing  added  to  the  site.  If  the  community 
were  involved  in  future  efforts  such  as  these,  it  would  most  likely  garner  additional 
support  for  the  concept  and  add  to  its  chance  of  success. 

4.  Database  Integration 

The  last  area  of  future  work  is  likely  the  most  important.  The  issues  associated 
with  the  current  state  of  data  in  the  NAVPERSCOM  legacy  system  have  been  mentioned 
previously.  In  order  to  make  this  entire  concept  a  reality,  the  maintenance  of  the  data 
would  need  to  be  as  simple  as  possible  and  require  little  interaction  on  the  part  of  the 
detailing  office  staff  In  order  to  make  the  concept  viable,  the  detailing  office  would  have 
to  be  willing  to  maintain  the  data.  In  order  to  prevent  the  duplication  of  data,  an 
integration  method  between  the  legacy  system  and  the  portal  database  should  be 
established.  This  could  come  in  the  form  of  a  direct  connection  to  the  NAVPERSCOM 
system,  but  this  option  is  highly  unlikely.  A  realistic  goal  would  be  to  create  an  import 
routine  that  would  update  this  system  using  the  ASCII  text  file  output  from  the 

mainframe  system.  Another  research  project  is  currently  underway  to  accomplish  this 
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very  task.  The  initial  development  of  the  data  model  for  both  of  these  projeets  was  done 
simultaneously;  however,  additional  changes  are  expected  in  model  for  the  other  research 
project.  This  research  is  not  yet  complete.  When  it  is  completed,  it  will  meet  one  of  the 
primary  requirements  for  the  progression  of  this  portal  to  a  working  implementation. 
This  portal  research  would  have  to  be  revisited  upon  completion  of  the  data  integration 
research  in  order  to  assess  changes  to  the  data  model  and  evaluate  its  use  with  the 
existing  portal  web  pages. 

C.  FINAL  THOUGHTS 

This  project  started  with  a  grand  vision  in  the  mind  of  one  student.  The  result  is 
not  the  full-blown  production  model  that  was  initially  envisioned,  but  the  research  did 
address  the  primary  question  of  what  a  prototype  model  for  a  Civil  Engineer  Corps 
Community  portal  could  look  like.  A  successful  working  prototype  with  database  and 
website  were  created,  and  the  concept  was  proven  as  a  viable  information  delivery  tool 
for  use  by  the  community.  Portions  of  the  portal  could  be  implemented  with  little  to  no 
additional  work.  Other  parts  require  additional  work  to  implement  successfully  -  some  of 
which  is  ongoing.  As  stated  in  the  beginning,  the  internet  has  become  a  powerful  tool  for 
providing  information  to  almost  anyone,  anywhere.  This  project  proves  that  this  concept 
can  be  extended  to  this  community  to  provide  a  wealth  of  information  to  a  myriad  of 
officers  around  the  world. 
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APPENDIX  A:  PI  SAMPLE  PAGES 


PAGE  IS  REPRESENTATIVE  OE  EORMAT,  BUT  CONTAINS  NO  VALID  DATA 


Civil  Engineer  Corps  Active  Duty  Personnel 


Page 

Number 

Name 

Rank 

Year 

Group 

Aetivity  Name 

PCode 

Designator 

34 

SALTER,  JEFFREY  MITCHEL 

LCDR 

1986 

NAVSUPPACT  NEW 

IIOIP 

5100 

100 

SANDERS,  SCOT  T 

LT 

1992 

ENGFEDACT  MED 

IIOIP 

5100 

16 

SASEK,  DAVID  JOHN 

LCDR 

1987 

COM  THREE  ONE  NCR 

IIOIP 

5100 

36 

SCANLAN,  STEVEN  RAYMOND 

CDR 

1982 

CG  MCB  CAMP  LEJEUNE 

IIOIP 

5100 

84 

SCHANZE,  CHRISTOPHER  NMN 

CAPT 

1978 

PACNAVFACENGCOM 

IIOIP 

5100 

59 

SCHILLING,  LEONARD  CARL 

LT 

1992 

NAVSUBASE  KINGS  BAY  GA 

IIOIP 

5100 

83 

SCOTT,  BRIAN  MERRITT 

CDR 

1981 

ROICC  MID-PACIFIC 

IIOIP 

5100 

23 

SHEEDY,  WILLIAM  MALCOLM 

LCDR 

1986 

NAF  ATSUGI  JAPAN 

IIOIP 

5100 

46 

SHOEMAKER,  JERRY  J 

LT 

1992 

CBC  PORT  HUENEME  CA 

IIOIP 

5100 

5 

SNOW,  RALPH  GORDON 

CDR 

1983 

CINCPACFLT  PEARL 

IIOIP 

5100 

92 

STILL,  AARON  MICHAEL 

LT 

1996 

NMCB  FOUR 

IIOIP 

5100 

85 

STOLL,  MICHAEL  JOHN 

CDR 

1982 

COMNAVFACENGCOMHQ 

IIOIP 

5100 

60 

STRATMAN,  ALLAN  MARK 

LCDR 

1986 

NMCB  THREE 

IIOIP 

5100 

61 

SURASH,  JOHN  E 

CAPT 

1976 

COMNAVFACENGCOMHQ 

IIOIP 

5100 

121 

SYKES,  MARSHALL  TROUTMAN 

LCDR 

1988 

FACILITIES  PROGRAM 

IIOIP 

5100 
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PAGE  IS  REPRESENTATIVE  OE  EORMAT,  BUT  CONTAINS  NO  VAEID  DATA 


EEA  SOUTHEAST  EISTING 


Page 

Activity  Name 

UIC 

Commercial  Phone 

35 

PWC  JACKSONVILLE  FL 

68931 

(904)  589-0943 

ENGFLDACT  SOUTHEAST  JACKSONVILLE  FL 

44226 

(904)  930-9398 

NAS  JACKSONVILLE  FL 

00207 

(904)  399-9388 

36 

NAVSPTEL  BICMD  JACKSONVILLE  FL 

32264 

(904)  939-3990 

NAVHOSP  JACKSONVILLE  FL 

00232 

(904)  849-9487 

NAVAVNDEPOT  JACKSONVILLE  FL 

65886 

(904)  653-9489 

HLTHCARE  SUPPO  JACKSONVILLE  FL 

68907 

(904)  849-4985 

COMNAVREG  SE  JACKSONVIELE  FL 

09697 

(904)  859-9494 

37 

CBU  FOUR  ONE  ZERO  JACKSONVILLE  FL 

66671 

(904)  843-4899 

NAS  MAYPORT  FL 

68709 

(904)  985-9585 

NAVSTA  MAYPORT  FL 

60201 

(904)  849-4994 

38 

CBU  FOUR  TWO  ZERO  MAYPORT  FL 

55162 

(904)  445-9488 

NAVSUBASE  KINGS  BAY  GA 

42237 

(912)  938-3948 

EFA  SE  CONT  OFC  KINGS  BAY  GA 

68248 

(912)  943-3933 

SWFLNT  KNGS  BAY  GA 

68733 

(912)  343-4944 

39 

CBU  FOUR  ONE  TWO  KINGS  BAY  GA 

66672 

(912)  839-3930 
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APPENDIX  B:  CEC  BIWEEKLY  SAMPLE 


CEC  Biweekly  07  June  2002 


Chief  of  Civil  Engneers 

CEC  Biweekly 

07  June  2002 


In  This  Issue 

TYfla  ('.F  r.  rjiplnm  .Slag  SnlftiJitwa 

MenHifantliiiii  <it  HiKlerslanduMj  Siyneil  lui  Riila  Ci.iivirii'lmii 

2<.Ki2Lataal  Irareler  BoafJ 

Itfims  of  Intaesl 

Awards 

Aikln-ss  IJlainf*;  IllliUllialiim 

nr  C!  Rmjpfrifty  tnpi<  Infr^niatu-in 

n.Pn  Rimppkly  Past 


FY03  CEC  Captain  Staff  Selections 


NAVFAC 


Seabees 


NCTC 


U.S.  Navy 


Dealer 


The  following  active  duty  Civil  Engineer  Corps  officers  have  been  selected  for  promotion  to  Selection  Boards 

Captain 


CDR  Michael  L  Blount 
CDR  David  M  Boone 
CDR  David  M  Biimes 
CDR  Franas  P  Castaldo 
CDR  Mason  Cnim 
CDR  David  L  Fleisch 
CDR  Paul  T  Fuligm 
CDR  Katherine  L  Gregory 
CDR  Apnl  F  Hemze 


CDR  Flugh  R  Hemstreet 
CDR  Kevm  A  Lindsey 
CDR  Barry  K  Loveless 
CDR  Gerald  R  Manley 
CDR  Roger  M  Natsuhara 
COR  Michael  J  O'Connor 
CDR  Enc  S  Odderstol 
CDR  Robert  P  Walden 


The  following  active  limited  duly  Civil  Engineer  Corps  officer  has  been  selected  for 
promotion  to  Captam 


CECOS 


NFACT 


Parsp  active 


Professional 

Reading 


Recruiting 


Trie  are 


CDR  David  C  Phillips 


The  following  reserve  Civil  Engineer  Corps  officers  have  been  selected  for  promotion  to 
Captain 


CDR  Kenneth  C  Alexander 
CDR  Paula  C  ELrown 
CDR  Stephen  E  Elrod 
CDR  Timothy  W  Hamberg 
CDR  Larry  A  Ffibner 
CDR  Robert  V  Huffman 
CDR  Robert  H  Kelly 
CDR  Mark  E  Kislner 
CDR  Herve  M  Kopciak 
CDR  Donald  E  Kuellmer 
CDR  T errence  M  Mahoney 
CDR  Robert  S  Meyer 


CDR  Hans  Probst  Jr 
CDR  Ricky  V  Ftichards 
CDR  Gregory  R  Ftismller 
CDR  Charles  E  Silva 
CDR  Joel  E  Sirm 
CDR  Theodore  E  Spear 
CDR  David  L  Sullivan 
CDR  Douglas  P  Taylor 
CDR  Michael  G  Ward 
CDR  William  R  Whittenberg 
CDR  Terry  L  Wilkerson 
CDR  James  R  Wood 
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CDR  David  K  Mon  CDR  Tmodiy  G  Zakflsk( 

CDR  Scott  A  Mofns 
CDR  Thomas  P  Newdome 

The  following  reserve  limited  duty  Civil  Engineer  Corps  officer  has  been  selected  for 
promotion  to  Captan 

CDR  James  T  Conen 

back  to  l0L> 


2002  Lateral  Transfer  Board 


Congratulations  to  the  folowmg  officers  who  were  recently  selected  for  transfer  to  the  Civil 
Engineer  Corps 

LT  Thomas  M  Bestalka.  Chemical  Engineenng.  NRD  New  York 

LT  Daryl  J  Lotempio.  CivJ  Engineenng,  USS  BRDGE 

LT  Wallace  M  Mattos.  Civil  Engineenng,  NAVSEA 

LT  Daniel  M  Schormann,  Mechanical  Engineenng,  NRD  San  Antonio 

LT  Andrew  J  Sulivan,  Civil  Engineenng,  JCS 

LT  Robert  G  Tetreault,  Ocean  Engineenng,  EWTG  Lant 

LTJG  Marisa  K  Barrie,  Mechanical  Engineenng,  NPTU  Charleston 

LTJG  Angelo  D  Fonlanazza,  Systems  Engineenng.  USS  GEORGE  WASHINGTON 

LTJG  Sarah  L  Franson,  Civil  Engineering,  NAVSAFECEN 

LTJG  Wesley  W  Hamill.  Civil  Engineering.  USS  MORISON 

LTJG  Bnan  J  Longbottom,  Civi  Engineenng,  USS  RM  DAVIS 

LTJG  Roberto  Maldonado.  Mechanical  Engineering,  USS  ARCTIC 

LTJG  Edw»d  B  Miller.  Civil  Engineering.  PHIBRON  EIGHT 

LTJG  David  B  Noya,  Mechanical  Engineenng,  CSRO  San  Diego 

LTJG  Megan  M  Pagano,  Engineenng  Science,  USS  HIGGINS 

LTJG  Pablo  F  Sierra.  Aerospace  Engineenng,  USS  GONZALEZ 

ENS  Jeffrey  A  Breisford,  Industnal  Engineenng,  USS  HERON 

ENS  Danny  Cerezo,  Architecture,  USS  ANTIETAM 

ENS  Constance  L  Danner,  Civ(  Engineenng,  USS  SPFtUANCE 

ENS  Matthew  J  Gaudet.  Mechanical  Engineering,  USS  JUNEAU 

Congratulations  to  the  following  Civil  Engineer  Coips  who  were  selected  for  augmentation 
to  the  Regular  Navy 


LT  Jay  A  Bieszke 
LT  Deanna  S  Carpenter 

LT  Michael  A  Comstock 
LT  Patnck  T  Connor 
LT  Damy  H  Cruz 
LT  James  D  Ekberg 
LT  LatKe  M  Flood 
LT  Joshua  J  Gamez 
LT  Cassie  A  Gorman 
LT  Julie  A  Hrdlicka 


LT  Ronald  J  Jenkins 
LT  Jason  G  Kranz 
LT  Phillip  M  Lavallee 
LT  Gerald  C  Lowe 
LT  Thomas  B  McLemore 
LT  Joseph  C  Pope 
LTJG  Bnan  L  Clapp 
LTJGEncW  Hahn 
LTJG  Marc  F  Williams 


hark  tfi  >fip 
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•  For  the  Irst  time.  "Joinf  J4  Engmeers  from  the  United  States  Joint  Forces  Command 
(USJFCOM)  attended  the  Contingency  Engineering  Seminar  at  the  Civ(  Engrieer 
Corps  Officers  School  (CECOS)  in  Port  Hueneme,  Calif  The  one -week  class  was 
designed  to  improve  the  effectiveness  of  those  who  may  have  to  provide  operational 
engineenng  support  in  a  Joint  T ask  F  orce  (JTF)  environment  It  addressed  the 
organization  of  joinl  task  forces,  DoD  and  avdian  engineering  capability,  |oint 
engineer  functions,  civil  engineer  support  planning,  facility  acquisition  management, 
host  nation  support,  and  capabilities  of  U  S  and  international  contingency 
organizahons  While  hosted  by  CECOS,  the  course  included  not  only  instructors  from 
CECOS,  but  also  a  host  of  visiting  instructors  from  Navy,  Manne  Corps,  Air  Force, 
and  Army  They  represented  various  commands  such  as  U  S  Southern  Command, 
Naval  F  acilities  Engineering  Command,  1st  Marine  Expeditionary  Force  and  the 
National  Emergency  Preparedness  Liaison  Office 

•  A  nbbon  cutting  ceremony  was  held  recently  for  a  new  wharf  constructed  m  San 
Diego  Bay,  Calif .  to  support  the  USS  NIMfTZ  (CVN  68)  which  is  scheduled  to  make 
San  Diego  its  new  home  sometime  this  fall  Besides  the  new  wharf,  a  storage 
warehouse,  equipment  staging  building,  and  a  fleet  recreation  center  was  also  built 
The  90  teet  wide  by  1 ,300-feet  long  wharf  runs  parallel  with  San  Diego  Bay.  and 
connects  to  a  recently  completed  pier  where  USS  JOHN  S  STENNIS  (CVN  74)  is 
berthed  SOUTHWESTDIV  managed  the  contract  for  the  project,  which  is  valued  at 
approximately  $51  3  million 

hack  In  top 


Awards 


Defense  Meritorious  Service  Medal 

LT  Whitley  H.  Robinson ,  CEC.  USN,  March  1 999  to  April  2002  As  Officer  in  Charge, 
Special  Programs  Office,  Metro  Field  Office,  Policy,  Rans,  and  Requirements,  White  House 
Miliary  Office,  established  working  relationships  with  more  than  16  government 
departments  and  agenaes  to  create  unity  of  effort  for  a  cntical,  large-scale  classified 
project  Drected  a  project  directed  by  the  White  House  Chief  of  Staff,  completing  all  actions 
in  two  weeks  Led  the  renovation  of  a  F>residenlial  command  center,  acceleratng  the 
schedule  by  85  percent  wNe  integrating  complex  and  changing  requirements  levied  by 
senior  White  House  Staff 

Meritorious  Service  Medal 

CAPT  Brian  M.  Scott,  CEC,  USN,  June  1999  to  May  2002  As  ROICC,  Peart  Harbor. 
Hawaii,  executed  a  $778  mllion  acquisition  program  throughout  Hawaii,  Johnston  Alol.  and 
Wake  Island  knplemenled  innovative  process  improvements  that  resulted  in  enhanced 
acquisition  planning  and  engineering  integration  and  produced  an  annual  savings  of  $7  9 
rmlhon  Led  the  ROICC  team  in  executing  a  myriad  of  technically  complex  and  time- critical 
projects,  includmg  the  $18  million  renovabon  of  the  Commander,  Paafic  Fleet  Headquarters 
and  a  $32  imlhon  construction  project  to  provide  consotidated  waterfront  piers  at  Naval 
Station  Pearl  Harbor 

CDR  Michael  J.  Stoll.  CEC.  USN.  July  1998  to  September  2001  As  Fhjbbc  Works  Officer, 
Naval  Air  Stabon  Oceana,  Virginia  Beach,  Va  ,  consolidated  three  pubkc  works  operations 
serving  NAS  Oceana.  Fleet  Combat  Training  Center  Atlantac,  and  the  Public  Works  Center. 
Virginia  Beach  site  into  a  single  team  Improved  the  combined  organization's  efficiency  and 
effectiveness  and  reduced  overhead,  resulhng  in  an  annual  savings  of  more  than  $2  5 
million  Orchestrated  facilities  jxeparabons.  including  $100  million  »i  consbuction  required 
to  meet  the  base  realignment  and  closure -directed  receipt  of  10  F/A-18  squadrons  and 
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hai*  III  I<||| 


Military  Personnel  Information 


CDR  Kevin  R  Slates  to  MCB  Camp  Lejeune,  N  C 
LCDR  Bradley  S  Hancock  to  CNET,  Pensacola.  Fla 

LCDR  Michael  P  Oestereichef  to  EFA  NORTHEAST  Contracts  Office.  Brunswick.  Mane 
LT  Karl  R.  Cupp  to  (DUINS)  Colorado  University,  Boulder.  Colo 
LT  Sarah  L  Deutermann  to  LANTDIV  Contracts  Office,  Sewells  Point.  Va 
LT  Joseph  L  Greeson  to  22ND  NCR.  Gulfport,  Miss 
LT  Chnstopher  J  Lee  to  NAS  Sigonella,  Italy 

LT  Matthew  P  Lesser  to  EFA  NORTHEAST  Contracts  Office,  Earle,  N  J 
LT  Thomas  J  Lyons  to  SOUTHWESTDIV,  San  Diego,  Calif 
LT  Joshua  B  Malkin  to  (DUINS)  University  of  Maryland.  College  Park,  Md 
LT  Jeffrey  E  McCoy  to  NMCB  FOUR,  Port  Hueneme,  Calif 
LT  James  G  Meyer  to  OICC  MED  Contracts  Office.  Sigonella,  Italy 
LT  Cnstopher  P  Neish  to  (DUWS)  Georgia  Tech.  Atlanta.  Ga 
LT  Stephen  H  Pitman  to  PACDIV  DET  MIDPAC,  Peart  Harbor.  Hawaii 
LT  Russell  C  Rang  to  LANTDIV.  Norfolk.  Va 
LT  Mikhael  H  Ser  to  22ND  NCR.  Gulfport,  Miss 

LT  William  A  SprauerJr  to  (DUINS)  University  of  Texas,  Houston,  Texas 

LT  Neil  E  West  to  (DUINS)  Colorado  University,  Boulder,  Colo 

LT  Ra  Yoeun  to  (DUINS)  University  of  Maryland,  Colege  Park,  Md 

LTJG  Jason  A  Edelberg  to  EFA  CHES,  Washington.  D  C 

LTJG  Dustin  Kwok  to  NAVACTS  United  Kingdom.  London 

LTJG  Shawn  P  Pope  to  NAVBASE  Ventura  County,  Point  Mugu,  Calif 

ENSEnwinA  Rico  to  NMCB  ONE.  Gulfport.  Miss 

ENS  Preston  D  Taylor  to  NMCB  40,  Port  Hueneme,  Calif 

ENS  Enk  P  Ulmen  to  22ND  NCR,  Gulfport,  Miss 

back  to  too 


CEC  Biweekly  Address  Changes 

Active  duty,  reserve,  and  retired  e-mail  addresses  may  be  updated  online.  For  acbve 
duty  Civil  Engineer  Corps  officers,  visit  www  naufrif.  mil'.:.-!,:  cfin  .  For  reserve 

Civil  Engineer  Corps  officers,  visit  mAA/w  npiyfa.-,  n.-4vy  miL'r.ftt-.  ljsLT(-,.sf.fvt--,  t.hn  Retred  CEC 
oficers  can  now  provide  their  e-mail  addresses  to  receive  the  electronic  CEC  Biweekly  by 
visiting  WWW  iiavbr.navy  r.fm  AN  CEC  officers  Should  keep  ther  e  -mail 

addresses  current  within  the  system  as  these  e-mail  addresses  will  also  be  used  to 
disseminate  other  offiaal  mformabon 

For  acbve  duty  officer  address  changes,  please  contact  Dennis  Potter  at  DSN  882-4031 , 
commeraal  (901)  874  -4031 ,  or  send  an  e  -mail  to  p4413s(^persnet  navy  md  For  reserve 
officer  address  changes,  contact  John  Anderson  at  (202)  685  -9014  or  e  -mait  at 
andefSQrufrfig^iiavfati.navy  mil 


back  to  top 
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If  you  have  information  you  vrould  bke  to  submit  to  the  CEC  Biweekly,  mail  to  the  address 
below  or  send  an  e-mail  to  Drema  McCoy  at  mccoydniignaufac  navy  mil  You  may  also  call 
her  at  DSN  325-9008,  commercial  (202)  685  -9008  or  fax  at  (202)  685  -1484  If  you  have 
award  information,  please  fax  or  mail  a  copy  of  the  signed  citation 

CEC  Biweekly 

Naval  Faalltles  Engineering  Command 
1322  Patterson  Ave.  SE.  Suite  1000 
Washington  Navy  Yard.  D  C  20374-5065 

back  to  loo 
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APPENDIX  C:  DATABASE  SCHEMA 


Entity  Name 

Description 

ACTIVITY 

This  entity  contains  information  related  to  commands  to  which  Civil  Engineer  Corps  officers  are  assigned. 

Field 

1 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

ActivitvID 

✓ 

Uniquely  identifies  activity 

Integer 

Autonumber 

✓ 

Name 

Command  name 

VaiChar(75) 

✓ 

UIC 

ip;3!iinin 

✓ 

Claimancv 

Claimancv 

Region 

NAVFAC  Region 

VaiCharC25) 

Lookup  Table 

✓ 

Street  1 

1  St  line  of  stre  et  addre  s  s 

VarCharC50) 

✓ 

Street  2 

2nd  line  of  street  address 

VarCharOT 

streets 

3rd  line  of  street  address 

VarCharOT 

Street  4 

4th  line  of  stre  et  addre  s  s 

VarChar(5QD 

Citv 

VarCharC25) 

✓ 

State 

State 

VarCharCT) 

Lookup  Table 

✓ 

Zip 

Zip  code 

VarChar(5) 

✓ 

ZipPlusFoiir 

Plus  4  zip  code 

VarCharC4) 

Country 

VaiCharC25) 

lODigjtCode 

MtlltQiliil 

Entity  Name 

Description 

ACTIVITY  PHONE 

This  entity  contains  phone  number  information  for  activities. 

Field 

Properties  I 

1 

B 

Descry  tion 

Type  (kngth) 

Allowable 

Values 

Required 

A  ctivityPhonelD 

✓ 

Uniquely  identifies  phone 
number 

Integer 

Autonumber 

V' 

ActivitylD 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

V' 

Type 

Type  of  number 

VarChara5) 

Lookup  Table 

V' 

CountyCode 

Country  code 

VarChar(:5) 

AreaCode 

AreaCode 

VarChar  C5) 

Number 

Phone  Number 

VarChar(20) 

V' 

Extension 

Extension 

VarChar 

Entity  Name 

Description 

MEMBER 

This  entity  contains  information  related  to  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

1 

B 

Descry  tio  It 

Type  (length) 

Allowable 

Values 

Required 

MemberlD 

✓ 

Uniquely  identifies  member 

Integer 

Autonumber 

FirstName 

First  name 

VarChar  (25) 

MiddleName 

Middle  initial 

VarChar  C7) 

LastName 

Last  name 

VarChar  (25) 

NickName 

Go-by  name 

Suffix 

Name  suffix 

VarChar  (5) 

Lookup  T  able 

SSN 

v' 

Rank 

Rank 

VarChar  (7) 

Lookup  Table 

v' 

Designator 

Designator 

Lookup  Table 

v' 

Race 

Race 

Lookup  Table 

Sex 

Sex 

Lookup  Table 

YeaiGroup 

Year  Group 

Lookup  Table 

v' 

Username 

Portal  Username 

VarChar  C20D 

Password 

Portal  Password 

VarChar  (20) 

UserLevel 

■ 

■ 

PortalUser  Access  Level 

VarChar(l^ 

Administrator 

User 

■ 

■ 
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Entity  Name 

Description 

ADDRESS 

This  entity  contains  address  information  for  members  of  the  Civil  EngineerCorps. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

AddressID 

✓ 

Uniquely  identifies  addresses 

Integer 

Autonumber 

✓ 

MemberlD 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

✓ 

Type 

Type  of  address 

VaiChara5) 

Lookup  Table 

✓ 

Street  1 

1  St  line  of  stre  et  addre  s  s 

VaiCharOT 

✓ 

Street  2 

2nd  line  of  street  address 

VarCharOT 

Streets 

3rd  line  of  street  address 

VarCharC50) 

Street  4 

4th  line  of  stre  et  addre  s  s 

VaiCharOT 

City 

City 

VarCharC25) 

✓ 

State 

State 

VarCharO) 

Lookup  Table 

✓ 

Zip 

Zip 

VarChari:5) 

✓ 

ZipPlusFour 

Plus  4  zip  code 

VarChari:4) 

Country 

Country 

VarCharC255 

Entity  Name 

Description 

PHONE 

This  entity  contains  phone  information  for  members  of  the  Civil  Engineer  Corps. 

Field 

1 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

PhonelD 

✓ 

Uniquely  identifies  phone 
number 

Integer 

Autonumber 

✓ 

MemberlD 

D 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

✓ 

Type 

Type  of  number 

VaiChara5^ 

Lookup  Table 

✓ 

CountryCode 

Country  code 

VarChar(5) 

AreaCode 

AreaCode 

VaiChar(5) 

Number 

Phone  Number 

Extension 

Extension 

VaiCharCS) 

Entity  Name 

Description 

EMAIL 

This  entity  contains  e-mail  addresses  for  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

PK 

FK 

Descry  tio  It 

Type  (kngth) 

Allowable 

Values 

Required 

EMaillD 

✓ 

Uniquely  identifies  phone 
number 

Integer 

Autonumber 

MemberlD 

■/ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

Type 

Type  of  e-mail 

Lookup  Table 

✓ 

■ 

■ 
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Entity  Name 

Desctiption 

MEMBER  BILXET 

This  entity  contains  information  necessary  to  relate  community  members  to  billets. 

Field 

1 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

MemberlD 

✓ 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

y/ 

BiUetlD 

✓ 

✓ 

y/ 

RepoftDate 

Report  date 

Date/Time 

MM/DDAT\T 

y/ 

PRD 

Project  Rotation  D ate 

Date/Time 

MM/DD/mr 

y/ 

DisplavDate 

Date  to  display  on  portal 

Date/Time 

MM/DDATYY 

V' 

Entity  Name 

Description 

MEMBER  QUAUFICATION 

This  entity  contains  information  necessary  to  relate  qualifications  to  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

MemberlD 

✓ 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

✓ 

QualificationID 

✓ 

✓ 

✓ 

Entity  Name 

Description 

MEMBER  PCODE 

This  entity  contains  information  necessary  to  relate  pcodes  to  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (kngth) 

Allowable 

Values 

Required 

MemberlD 

y' 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

y/ 

PCodelD 

✓ 

y/ 

1 

Entity  Name 

Description 

BILLET 

This  entity  contains  information  related  to  billets  for  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

1 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

BilletID 

✓ 

Uniquely  identifies  billet 

Long  Ineger 

Autonumber 

v' 

ActivitvID 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

v' 

PCodelD 

✓ 

BSC 

Billet  Sequence  Code 

VarCharClCh 

v' 

Description 

Short  name  of  billet 

VarCharOT 

y/ 

Category 

Billet  Category 

VarCharC25) 

Lookup  T  able 

y/ 

Rank 

Rank  re  quire  d  for  billet 

VarChartD 

Lookup  Table 

Designator 

D  e  signator  re  quire  d  for  billet 

VarCharCD 

Lookup  T  able 

Active 

Indicates  billet  active/inactive 

Boolean 

Yes 

No 

y/ 

StartDate 

Start  date  for  billet  availability 

Date/Time 

MM/DDATYY 

EndDate 

End  date  for  billet  availability 

Date/Time 

MM/DDATYY 

Entity  Name 

Description 

BILLET  QUAUFICATION 

This  entity  contains  information  necessary  to  relate  qualifications  to  billets. 

Field 

Properties  I 

i 

B 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

MemberlD 

✓ 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

y/ 

QualificationID 

✓ 

✓ 

y/ 

Status 

Indicates  primary  or  seconday 
qualific  ation  c  o  de  for  billet 

VarChar(iq) 

Primary 

Secondary 

y/ 

■ 

■ 
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Entity  Name 

Description 

PCODE 

This  entity  contains  pcode  information  for  members  and  billets  of  the  Civil  Engineer  Corps. 

FieU 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

PCodelD 

✓ 

Uniquely  identifies  a  pcode 

Integer 

Autonumber 

✓ 

PCode 

Professional  Code 

VarChar(7) 

✓ 

Description 

Professional  Code  Description 

VaiChar(i^ 

✓ 

Entity  Name 

Description 

QUAUFICATION 

This  entity  contains  qualification  information  for  members  and  billets  of  the  the  Civil  EngineerCorps. 

Field 

Properties  I 

I 

Descry  tion 

Type  (length) 

Allowable 

Values 

QualificationID 

✓ 

Uniquely  identifies  a 
qualification 

Integer 

Autonumber 

AQD 

Qualification  Code 

VarChar(7) 

Description 

Description  of  qualification 

VarCharC^OD 

y/ 

Entity  Name 

Description 

AWARDS 

This  entity  contains  awards  received  by  members  of  the  Civil  Engineer  Corps. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

AwardID 

✓ 

Uniquely  identifies  award 

Integer 

Autonumber 

y/ 

MemberlD 

✓ 

F  oreign  key  prop  erty  information  provide  d  in  foreign  table 

y/ 

DisplayDate 

Portal  display  date 

Date/Time 

MM/DDAT 

y/ 

Award 

Award  name 

VarCharCJO) 

y/ 

Description 

Detailed  award  description 

Memo 

y/ 

Entity  Name 

Description 

UNKS 

This  entity  contains  links  to  professional  information  needed  by  members  of  the  Civil  Engineer  Corps. 

Field 

1 

B 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

UnkID 

✓ 

Uniquely  identifies  a  link 

Integer 

Autonumber 

y/ 

Category 

Information  category 

iMeliHIniil 

Lookup  Table 

y/ 

URL 

Worldwide  Web  URL 

Hyperlink 

y/ 

Entity  Name 

Description 

NEWS 

This  entity  contains  news  updates  for  Civil  Engineer  Corps  commurrity  items  of  interest. 

Field 

Properties  I 

PK 

FK 

Descry  tio  It 

Type  (length) 

Allowable 

Values 

Required 

N  ewsID 

✓ 

Uniquely  identifies  news 

update 

Integer 

Autonumber 

y/ 

✓ 

y/ 

DisplayDate 

Portal  diplay  date 

y/ 

News 

News  update 

y/ 

■ 

■ 

■■■■■ 
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Entity  Name 

Description 

lookupCATEGORY 

This  entity  contains  lookup  values  for  catergories  of  billets. 

Field 

Properties  I 

1 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

CategoivID 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

y/ 

Categoiy 

Billet  categoiy 

VaiCharC;2^ 

Seabee  Combat  Warfare 

Acquisition  Professional 

Public  Works  Management 

Staff 

General 

School 

Entity  Name 

Description 

lo  okupC  ATEGORYlink 

This  entity  contains  lookup  values  for  catergories  of  web  links. 

Field 

Properties  I 

I 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

CategoiylD 

✓ 

Uniquely  identifies  a  category 

Autonumber 

y/ 

Categoiy 

Web  links  categoiy 

VaiChar(5a) 

Seabees 

Acquisitions 

Public  Works 

General 

y/ 

Entity  Name 

Description 

lookupDESIGNATOR 

This  entity  contains  lookup  values  for  military  designators. 

Field 

Properties  I 

PK 

FK 

Descr^tion 

Type  (length) 

Allowable 

Values 

Required 

Designator  ID 

Uniquely  identifies  a  category 

Integer 

Autonumber 

y/ 

Desigpiator 

Alphanumeric  designator  code 

VaiChar(7) 

5100,5105, 6530, 6531, 

6532, 7531,7535, 7530, 

1110,1115,1120,1125, 

1165,1175, 1310,1315, 

1320, 1390, 1395 

y/ 

Description 

Description  of  the  designator 

VaiChar(lOO) 

ACTIVE  DUTY  CIVIL  ENGINEER  CORPS  OFFICER 

ACTIVE  DUTY  RESERVE  CIVIL  ENGINEER  CORPS  OFFICER 
CIVIL  ENGINEER  CORPS  UMITED  DUTY  OFFICER  (TJDO) 
CIVIL  ENGINEER  CORPS  UMITED  DUTY  OFFICER  (TJDO) 
CIVIL  ENGINEER  CORPS  UMITED  DUTY  OFFICER  (TJDO) 
CIVIL  ENGINEER  CORPS  CHIEF  WARRANT  OFFICER  (CWO) 
CIVIL  ENGINEER  CORPS  CHIEF  WARRANT  OFFICER  (CWO) 
CIVIL  ENGINEER  CORPS  CHIEF  WARRANT  OFFICER  (CWO) 
SURFACE  WARFARE  QUAUFIED  URL  OFFICER 

SURFACE  WARFARE  QUAUFIED  URL  OFFICER 
SUBMARINE  WARFARE  QUAUFIED  URL  OFFICER 
SUBMARINE  WARFARE  QUAUFIED  URL  OFFICER 

URL  OFFICER  IN  TRAINING  FOR  SURFACE  WARFARE 
QUAUFICATION 

URL  OFFICER  IN  TRAINING  FOR  SUBMARINE  WARFARE 
QUAUFICATION 

URL  OFFICER  QUAUFIED  AS  A  NAVAL  AVIATOR 

URL  OFFICER  QUAUFIED  AS  A  NAVAL  AVIATOR 

URL  OFFICER  QUAUFIED  AS  A  NAVAL  FUGHT  OFFICER 
URL  OFFICER  IN  TRAINING  AS  A  NAVAL  AVIATOR 

URL  OFFICER  IN  TRAINING  AS  A  NAVAL  AVIATOR 

y/ 

Importance 

Used  for  sorting  of  designator 
by  order  of  community 
importance 

Integer 

y/ 

■ 

■ 
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Entity  Name 

Description 

lookupRACE 

This  entity  contains  lookup  values  for  race. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (knsth) 

Allowable 

Values 

Required 

RacelD 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

■/ 

Race 

T  ext  description  of  race 

VaiChar(7) 

White/Caucasian 

Black/Afitic  an  Americ  an 

Amercian  Indian/Alaskan  N  ative 

Asian  American/Pacific  Islander 

Hispanic/Latino^Tatina 

Other 

Undeclared 

■/ 

ShortRace 

One  letter  code  for  race 

VarCharO) 

W,  B,  I,  A,  H,  0,  X 

y/ 

Entity  Name 

Description 

lookupRANK 

This  entity  contains  lookup  values  for  rank. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

RankID 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

✓ 

Rank 

T  ext  description  of  rank 

VaiChar(7) 

ENS,  LTJG,  LT, 

LCDR,  CDR  CAPT, 

RDMU  RDMU, 

VADM,  ADM, 

CW01,CW02, 

CW03,  CW04 

✓ 

Imporance 

Allows  for  sorting  of  rank  by 
senionty 

Integer 

✓ 

Entity  Name 

Description 

lookup  REGION 

This  entity  contains  lookup  values  for  region. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

RegionID 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

y/ 

Region 

Civil  Engineering  Corp 

Division 

VarChar(3q) 

N  aval  District  Washington 

Atlantic  Division 

EFA  Mediterranean 

EFA  Chesapeake 

EFA  Northeast 

Southern  Division 

EFA  Southeast 

EFA  Midwest 

Southwe  st  Division 

EFA  West 

EFA  Northwest 

Pacific  Division 

y/ 

Entity  Name 

Description 

lookupSEX 

This  entity  contains  lookup  values  for  sex. 

Field 

Properties  I 

1 

8 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

SexID 

D 

Uniquely  identifies  a  category 

Autonumber 

y/ 

Sex 

Biological  identific  ation  from 
birth 

VarChar(l) 

M 

F 

y/ 
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Entity  Name 

Description 

lookupSTATE 

This  entity  contains  lookup  values  for  state. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

StatelD 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

✓ 

State 

State  identification 

VarChar(2) 

AK,  AL,  AR,  AZ,  CA, 

CO,  CT,  DC,  DE,  FU 

GA,  HI,  lA,  ID,  IL, 

IN,  K3,  KY,  LA,  MA, 

MD,  ME,  MI,  MN,  MO, 

MS,  MT,  NC,  ND,  NE, 

NH,  NJ,  NM,  NV,  NY 

OH,  OK,  OR,  PA,  RI, 

SC,  SD,  TN,  TX;  UT, 

VA,  VT,  WA,  WI,  WV, 

WY,  AW,  AP,  AA 

✓ 

Entity  Name 

Description 

lookupSUFFIX 

This  entity  contains  lookup  values  for  type  of  suffix. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

SuffixID 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

✓ 

Suffix 

Suffix  identification 

VarChai(5) 

I 

II 

III 

IV 

JR 

SR 
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Entity  Name 

Description 

lo  okupT  YPEaddres  s 

This  entity  contains  lookup  values  for  types  of  addresses. 

Field 

1 

Descry  tion 

T3fpe  (kngth) 

Allowable 

Values 

Required 

TvpelD 

✓ 

Uniquely  identifies  a  category 

Integer 

Autonumber 

Type 

T3rpe  of  address 

VaiChar(l^ 

Work 

Work2 

Home 

Home2 

Entity  Name 

Description 

lookup!  YPEemail 

This  entity  contains  lookup  values  for  types  of  email  addresses. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (kngth) 

Allowable 

Values 

Required 

TvpelD 

Uniquely  identifies  a  category 

Integer 

Autonumber 

y/ 

Type 

Type  of  e-mail  address 

VarChar(lli) 

Work 

Work2 

Home 

Home2 

Other 

y/ 

Entity  Name 

Description 

lo  okupT  YPEphone 

This  entity  contains  lookup  values  for  types  of  phone  numbers. 

Field 

Properties  I 

PK 

FK 

Descry  tion 

Type  (length) 

Allowable 

Values 

Required 

TvpelD 

D 

Uniquely  identifies  a  category 

Autonumber 

y^ 

Type 

Type  of  phone  number 

VaiChar(15) 

Work 

Work2 

Toll  Free 

DSN 

Fax 

Home 

Home2 

Mobile  Pager 

Other 

Commercial 

y/' 
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^  Award 

INAW  &  MARINE  CORPS  COMMENDATION  MEDAL 

Docription _ 

Meritorious  service  while  serving  as  Facilities  Management/Environmental  Officer  Naval  Submarine 
Base.  Kings  Bay,  Georgia  from  April  1 998  to  August  2000.  Lieutenant  Junior  Grade  Rader's 
exceptional  performance  resulted  in  unprecedented  success  as  the  Naval  installation  received  the 
FY98  and  FY99  Secretary  of  the  Navy  environmental  awards,  and  the  1999  state  of  Georgia 
chamber  of  commerce  environmental  leadership  award  He  orchestrated  an  in-house  base 
operating  services  contractor  and  self-help  resources  to  reduce  repair  parts  maintenance  dollars 
against  the  needs  of  a  1 .3  billion  dollar  infrastructure.  While  administering  a  1 5  million  dollar  facilities 
management  budget,  he  led  the  division  through  a  revitalization  period  which  resulted  in  increased 
efficiency  and  morale.  Lieutenant  Junior  Grade  Rader's  exceptional  professional  ability,  personal 
initiative,  and  loyal  devotion  to  duty  reflected  great  credit  upon  himself  and  were  in  keeping  with  the 
highest  traditions  of  the  United  States  Naval  service. 


Recipient  Display  Date 

[RADER  T]  _  [neIl  [sTTTIoOO 


Record;  l<  |  <  1 1  TT  ►  I  »l  |»*|  of  11 


n 

Title 

|Date  Set  for  Washington,  D.C.,  NAVFAC/CEC/Seabee  Anniversary  Ball 

News 

The  Washington,  D.C.,  NAVFAC/CEC/Seabee  Anniversary  Ball  will  be  held  on  9  March  at  the  Crystal 
Gateway  Marriot  in  Arlington,  Va.  It  will  mark  the  160th  anniversary  of  the  Naval  Facilities  Engineering 
Command,  the  1 35th  of  the  Civil  Engineer  Corps,  and  the  60th  of  the  Seabees.  As  is  tradition, 
NAVFAC  HQ  events  will  begin  at  1 1 :00  with  the  28th  annual  Seabee  Memorial  Service  at  the  Seabee 
Memorial  in  Arlington. 

During  the  ball,  the  Rear  Admiral  Lewis  B.  Combs  and  the  Steelworker  Second  Class  Robert  B. 
Stethem  awards  will  be  presented  to  individuals  who  have  made  outstanding  contributions  to  the 
legacy  of  the  Seabees.  T o  pay  special  recognition  to  the  Seabees'  60th  birthday,  the  Seabee 
veterans  who  helped  pave  our  way  to  victory  during  World  War  II  will  be  honored. 


Submitted  By 

[RADER  [NEIl 

Record;  1^  |  <  1 1  5  »  I  H  !►*!  of  18 


Display  Date 

[G  n  /2002 
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APPENDIX  E:  DETAILED  SITE  PLAN 


Login  Page 
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APPENDIX  F:  SECTION  508  SHORT  LIST 


1.  A  text  equivalent  for  every  non-text  element  shall  be  provided  (e.g.,  via  "alt", 
"longdesc",  or  in  element  content). 

2.  Equivalent  alternatives  for  any  multimedia  presentation  shall  be  synchronized 
with  the  presentation. 

3.  Web  pages  shall  be  designed  so  that  all  information  conveyed  with  color  is  also 
available  without  color,  for  example  from  context  or  markup. 

4.  Documents  shall  be  organized  so  they  are  readable  without  requiring  an 
associated  style  sheet. 

5.  Redundant  text  links  shall  be  provided  for  each  active  region  of  a  server-side 
image  map. 

6.  Client-side  image  maps  shall  be  provided  instead  of  server-side  image  maps 
except  where  the  regions  cannot  be  defined  with  an  available  geometric  shape. 

7.  Row  and  column  headers  shall  be  identified  for  data  tables. 

8.  Markup  shall  be  used  to  associate  data  cells  and  header  cells  for  data  tables  that 
have  two  or  more  logical  levels  of  row  or  column  headers. 

9.  Frames  shall  be  titled  with  text  that  facilitates  frame  identification  and  navigation. 

10.  Pages  shall  be  designed  to  avoid  causing  the  screen  to  flicker  with  a  frequency 
greater  than  2  Hz  and  lower  than  55  Hz. 

11.  A  text-only  page,  with  equivalent  information  or  functionality,  shall  be  provided 
to  make  a  web  site  comply  with  the  provisions  of  this  part,  when  compliance  cannot  be 
accomplished  in  any  other  way.  The  content  of  the  text-only  page  shall  be  updated 
whenever  the  primary  page  changes. 

12.  When  pages  utilize  scripting  languages  to  display  content,  or  to  create  interface 
elements,  the  information  provided  by  the  script  shall  be  identified  with  functional  text 
that  can  be  read  by  assistive  technology. 

13.  When  a  web  page  requires  that  an  applet,  plug-in  or  other  application  be  present 
on  the  client  system  to  interpret  page  content,  the  page  must  provide  a  link  to  a  plug-in  or 
applet  that  complies  with  §1 194.21(a)  through  (1). 

14.  When  electronic  forms  are  designed  to  be  completed  on-line,  the  form  shall  allow 
people  using  assistive  technology  to  access  the  information,  field  elements,  and 
functionality  required  for  completion  and  submission  of  the  form,  including  all  directions 
and  cues. 

15.  A  method  shall  be  provided  that  permits  users  to  skip  repetitive  navigation  links. 

16.  When  a  timed  response  is  required,  the  user  shall  be  alerted  and  given  sufficient 
time  to  indicate  more  time  is  required. 
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APPENDIX  G:  SAMPLE  MEMBER  UPDATE  FORMS 


Submit  an  Address 


City: 
State 
Zip 
Zip  +4 
Country: 


SEASIDE 

CA  0 

93955 

UNITED  STATES 

^  Submit  Address  1] 


Edit  Address 


Type  HOME  0; 
Street  1 


220  TUNISIA  ROAD 


Street  2 
Street  3 
Street  4 
City 


SEASIDE 


State  CA  0 
Zip 


93955 


Country 


UNITED  STATES 


(  Update  Address  ] 


Delete  Address 


Are  you  sure  you  want  to  delete  this  HOME  address  from  the  database? 
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APPENDIX  H:  SAMPLE  INFORMATION  DELIVERY  TOOLS 


All  Current  News 


Test  of  New  Civil  Engineer  Corp  Portal 

The  new  Civil  Engineer  Corp  Information  Delivery  Portal  prototype  is  complete.  Welcome  to  the  site.  Feel  free  to  explore  and  enjoy  the  resource.  Submit 
comment,  concerns,  or  suggestions  to  LT  Chris  Rader  at  ncradertgnps  .navy.  mil. 


EFA  CHES  ROICC  Office  Receives  CMAA  Award 

The  EFA  CHES  ROICC  office  recently  received  the  Construction  Management  Association  of  America's  (CMAA)  National  Capital  Chapter,  2001  Project 
Achievement  Award  for  the  newly  constructed  Glenn  Warner  Soccer  Facility  at  the  U.S.  Naval  Academy.  The  award  is  provided  annually  to  the 
construction  management  entity  that  best  exemplifies  professionalism  and  excellence  in  the  management  of  the  construction  process.  The  $4.5  million 
project  is  a  one  story  17,000  square  foot  building  consisting  of  a  home  team  wing  and  a  visitor  wing  on  either  side  of  a  two-story  high  domed  memorial 
lobby.  The  memorial  lobby  is  the  focal  point  for  displays  and  was  constructed  to  a  grade  of  finish  to  host  formal  functions.  The  wings  provide  coaches 
offices,  locker  rooms,  laundry  facilities,  training  room  and  shower  facilities.  A  concession  area  and  a  ticket  booth  were  also  incorporated  into  the 
visitors  wing.  ROICC  Annapolis  led  the  project  team  in  setting  up  a  master  schedule,  developing  a  procurement  strategy,  establishing  project 
performance  criteria,  selecting  the  design-builder,  design  development  and  construction  of  the  facility.  The  project  was  delivered  eight  months  early  and 
finished  by  original  contract  completion  date.  The  tight  schedule  led  ROICC  Annapolis  to  propose  design-build  delivery  system  which  allowed  completion 
of  the  project  in  13  months  vice  21  months  to  design-bid-buitd  and  use  of  the  facility  for  the  2001  soccer  season  vice  the  normal  design-bid-build 
approach  that  would  have  delayed  its  use  un^il  the  2002  season.  The  project  will  compete  for  the  National  CMAA  Achievement  Award  due  to  be  awarded 
August  02. 

PACDIV  Completes  Sewer  Force  Main  Installation 

PACOIV  and  ROICC  Pearl  Harbor  recerttly  installed  a  new  sewer  force  main  from  Ford  Island  to  the  Naval  Shipyard  at  Pearl  Harbor.  The  project,  which 
required  long  distance,  horizontal  drilling  in  soft  soil  at  the  bottom  of  the  harbor,  will  provide  approximately  1,820  meters  of  500mm  high-density 
polyethylene  (HOPE)  pipe  to  transmit  wastewater  from  Ford  Island  to  the  Naval  Shipyard.  The  project  will  also  upgrade  the  pumping  capacity  of  the 
existing  Ford  Island  pumping  station  project.  The  drilling  began  on  February  1  and  seven  hours  later,  an  equal  length  of  20-inch  high-density  polyurethane 
pipe  was  placed  beneath  Pearl  Harbor  waters.  The  excavation  wasn't  the  longest  attempted  but  it  is  i  mportant  because  of  the  difficulty  keeping  a  drill  on 
the  correct  path  in  soft  soil.  The  effort  is  part  of  a  $5.7  million  military  construction  (MILCON)  project  that  broke  ground  in  December  2001  and  has  an 
estimated  completion  date  of  July  2003.  ROICC  Pearl  Harbor  will  administer  the  contract. 

Seabee  Memorial  Scholarship  Applications  Due  15  April 

Do  you  know  of  someone  with  ties  to  the  Seabees  who  may  be  in  need  of  scholarship  assistance  for  college  tuition?  The  Seabee  Memorial  Scholarship 
Association  (SMSA)  may  be  able  to  help.  The  2002  SMSA  award  process  is  set  to  begin  with  the  acceptance  of  scholarship  applications  which  are  due 
no  later  than  15  April  2002.  Eligible  applicants  are  sons,  daughters,  stepchildren,  and  grandchildren  of  regular,  reserve,  retired,  or  deceased  officers  or 
enlisted  members  who  have  served  or  who  are  now  serving  with  the  Naval  Construction  Force  (Seabees)or  Navy  Civil  Engineer  Corps,  or  who  have 
served,  but  have  since  been  honorably  discharged.  The  basis  of  award  is  financial  need,  scholastic  aptitude,  leadership,  and  good  citizenship. 
Scholarships  are  for  four-year  bachelor's  degrees,  and  are  not  available  for  part  time  or  graduate  study.  The  annual  grant  is  renewable  for  up  to  four 
years  provided  the  recipient  maintains  eligibility.  Applications  may  be  found  on  the  SMSAwebsiteatwww.seabee.org.  Completed  applications  must  be 
received  or  postmarked  by  15  April  2002  and  mailed  to:  SMSA,  P.O.  Box  6574,  Silver  Spring,  MO  20916.  Applicartts  will  receive  notification  of 
application  receipt,  and  subsequent  results  in  July. 

PACDIV  Breaks  Ground  on  Environmental  Project 

PACDIV  broke  ground  7  February  on  a  military  construction  project  that  will  ultimately  improve  the  water  quality  in  the  Pearl  Harbor  estuary.  The  project 
will  construct  a  deep  ocean  outfall  that  will  discharge  treated  effluent  from  the  wastewater  treatment  plant  at  Fort  Kamehameha  on  Hickam  Air  Force 
Base  through  a  multiport  diffuser  into  open  coastal  waters.  PACDIV  awarded  the  $21.7  million  contract  in  June  2001  to  Healy  Tlbbitts  Builders,  Inc.,  of 
Aiea.  The  existing  outfall  at  Fort  Kamehameha  discharges  into  the  Pearl  Harbor  estuary,  which  is  classified  as  a  water  quality  limited  segment  (WQLS)by 
the  State  Department  of  Health.  Under  this  designation,  no  increase  of  wastewater  discharges  to  the  estuary  is  allowed.  Relocation  of  the  discharge  pipe 
to  open  coastal  waters  wi  1 1  el  i  mi  nate  di  soharge  to  the  WQ  L  S  of  Pearl  Harbor  and  the  associ  ated  future  per  mit  I  i  mitati  ons  or  vi  ol  ati  ons .  The  contractor  wi  1 1 
install  about  12,500  feet  of  48-inch  high-density  polyethylene  pipe  using  environmentally  sensitive  construction  practices.  Beginning  at  the  shoreline 
near  the  existing  treatment  plant,  a  trench  will  be  excavated  across  a  shallow  reef  area  using  heavy  construction  equipment.  The  excavated  material 
will  be  placed  next  to  the  trench,  providing  access  for  pipe  installation.  The  new  outfall  pipe  will  be  linked  to  the  existing  line  allowing  the  treated 
effluent  to  be  discharged  inrtothe  water  at  a  depth  of  about  150  feet. 
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NAVY  &  MARINE  CORPS  COMMENDATION  MEDAL 

Meritorious  service  while  serving  as  Facilities  Management/Environmental  Officer  Naval  Submarine  Base,  Kings  Bay,  Georgia  from  April  1998  to 
August  2000.  Lieutenant  Junior  Grade  Rader's  exceptional  performance  resulted  in  unprecedented  success  as  the  Naval  Installation  received  the  F Y98 
and  FY99  Secretary  of  the  Navy  environmental  awards,  and  the  1999  state  of  Georgia  chamber  of  commerce  environmental  leadership  award.  He 
orchestrated  an  in-house  base  operating  services  contractor  and  self-help  resources  to  reduce  repair  parts  maintenance  dollars  against  the  needs  of  a 
1.3  billion  dollar  infrastructure.  While  administering  a  15  million  dollar  facilities  management  budget,  he  led  the  division  through  a  revitalization  period 
which  resulted  in  increased  efficiency  and  morale.  Lieutenartt  Junior  Grade  Rader's  exceptional  professional  ability,  personal  initiative,  and  loyal 
devotion  to  duty  reflected  great  credit  upon  hi  mself  and  were  in  keeping  with  the  highest  traditions  of  the  United  States  Naval  service. 

Navy  and  Marine  Corps  Achievement  Medai 

LTJG  Andrew  J.  Shinka,  CEC,  USNR,  April  2000  to  February  2002.  As  AROICC,  Marine  Corps  Base,  Camp  Lejeune,  N.C.,  executed  20  contracts  valued  at 
more  than  $68  million  and  was  responsible  for  $17  million  work  in  place.  Led  the  construction  of  the  recon  facility,  renovation  of  11  bachelor  enlisted 
quarters,  and  completion  of  two  new  schools. 

Navy  and  Marine  Corps  Achievement  Medal 

LT  Russell  J.  Mattson,  CEC,  USN,  June  2001  to  December  2001.  As  Project  Manager,  NFESC,  led  the  $2  million  explosive  handling  wharf  repair  project 
at  Naval  Submarine  Base,  Bangor,  which  directly  supported  national  strategic  assets  during  a  period  of  immense  security  and  operational  constraints. 
Ensured  that  the  project  stayed  on  schedule,  within  budget,  and  was  completed  with  the  highest  standards  of  quality  while  minimizing  operational 
i  mpact . 

Navy  and  Marine  Corps  Commendation  Medai 

LT  Daniel  W.  Grippo,  CEC,  USN,  March  2000  to  November  2001.  As  Assistant  Public  Works  Officer,  Naval  Air  Engineering  Station,  Lakehurst,  N.J.,  led 
134  civilians  and  12  military  personnel  in  the  maintenance,  repair,  and  construction  of  more  than  $900  million  of  base  facilities,  resulting  in  more  than 
$1.5  million  in  annual  contract  savings  and  efficiencies  and  a  20  percent  reduction  in  contract  lead-time.  Led  the  facility  support  efforts  of  more  than  100 
base  and  community  volunteers  while  saving  more  than  $100,000  in  costs  and  providing  outstanding  service  for  more  than  400,000  visitors. 

Navy  and  Marine  Corps  Achievement  Medai 

ENS  Theodore  J.  Foster,  CEC,  USNR,  October  2001  to  November  2001.  As  AROICC,  National  Naval  Medical  Center,  Bethesda,  Md.,  performed  admirably 
as  the  Acting  ROICC  and  Acting  Supervisory  General  Engineer  in  the  wake  of  the  events  of  September  11.  Took  the  helm  firmly  in  the  absence  of  his 
supervisor  and  guided  the  office  through  difficult  year  end  acquisitions  while  personally  managing  16  high  visibility  construction  projects  valued  at  more 
than  $21  million. 
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LT  Neil  Rader  to  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  «  PGM/ASST  CIO 
LTJG  Nathan  Williams  to  NPS  STUDENTS  MONTEREY  CAas  STUDENT 
LT  Manuel  Hernandez  to  NPS  STUDENTS  MONTEREY  CAas  STUDENT 
LT  Neil  Rader  to  NPS  STUDENTS  MONTEREY  CAas  STUDENT 

LT  Whitley  Robinson  to  WHITE  HOUSE  M/0  WASH  DC  as  FAC  CONST/SVC/SPECIAL  PROGRAMS  OFF-09F 
CDR  David  Boone  to  WHITE  HOUSE  M/0  WASH  DC  as  FACPLN  «  PGM/SPEC  PGM  OFF  WHMO  M0010013 
LT  Thomas  Hunt  to  COMNAVFACENGCOMHQ  WASH  DC  as  MPWR  PLN/MIL  MPWR  OFF 
LT  Steven  Blanton  to  COMNAVFACENGCOMHQ  WASH  DC  as  AIDE/TO  THE  COMMANDER  •  OOA 
LCDR  THEODORE  POSUNIAKto  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  ENG/HD  CB  POL  &  DOCTRINE 
LT  Holly  Johnson  to  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  RSCH/SEALIFT  SUPP  «  MPF(E) 

LTTUAN  NGUYEN  to  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  ENG/BRAC  POLICY  MGR 
LT  Rolfe  Ashworth  to  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  &  PGM/FLD  OPS  PGM  OFF  PAC 
LCDR  Michael  Armesto  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  &  PGM/FLD  OPS  PGM  OFF  LANT 
LT  Michael  Teatesto  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  RSCH/NCF  PGM  OFF/DVG  GEN 
LCDR  Kevin  Hutsell  to  COMNAVFACENGCOMHQ  WASH  DC  as  EXEC  ASST/CDR  CONT  ENG  GRP 
CDR  MICHAEL  STOLLto  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  ENG/HD  HSG  PPV  COORD  OFF 
CDR  Cameron  Manning  to  COMNAVFACENGCOMHQ  WASH  DC  as  FAC  ENG/HD  PW  ADVOCACY 
CDR  Susan  Globokarto  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  «  PGM/ASST  DIR  BUS  ASSMT 
CAPT  Thomas  Calhoun  to  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  &  PGM/ASST  DIR  FLD  OPS 
CAPT  Philip  Dalbyto  COMNAVFACENGCOMHQ  WASH  DC  as  FACPLN  &  PGM/HD  CSSO 
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APPENDIX  I:  PROJECT  CD-ROM 


THE  PROJECT  CD-ROM  CAN  BE  EOUND 
IN  THE  LIBRARY  COPY  OP  THIS  THESIS 
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